C / C++ / MFC

7-May-04 10:07

I am having some difficulty and would like some view points on setting up the directory structure of projects that arent so small anymore.

Currently I have three parts to my project. The Core application and the Plugin are dialog based MFC programs.

1) Core Application
2) Common code
3) Plugin Framework

Each in a separate directory. The common code consists of utility functions, drawing routines, etc, which are shared between the core application and the Plugin Framework. One of my problems is that the MFC header file stdafx.h are all the includes for MFC stuff like CString. I don't want to hard code the path from the common directory back to my current project directory.

For example a file in the common directory needs to use CString but does not know what it is. I don't want to have to do this because I think it is bad technique.

#include "d:\project\stdafx.h"

I also don't want to do this

#ifdef CORE_APP
#include "d:\project1\stdafx.h"
#else
#include "d:\project2\stdafx.h"
#endif

As a result of moving all the files around I am now getting CString access violations and I am guessing it must have something to do with my poor file structure.

So what is a good approach for separating common files like in my situation?

Hope that made sense.

Maarten Kools7-May-04 10:22

7-May-04 10:22

Use include directories? Just specify these in the properties.

Steve Messer7-May-04 11:07

7-May-04 11:07

I did add an include for the common folder but how do files in the common folder see the stdafx.h for example in the project directory or is that bad technique.

So, if I include #include "stdafx.h" the files in the common directory can't find this file (duh). I guess I could add a file in the common directory called includes.h and include anything that the common files need.

John M. Drescher7-May-04 10:24

7-May-04 10:24

Access violations should have nothing to do with your file structure at all.

Are you using threads?

John

Steve Messer7-May-04 11:25

7-May-04 11:25

That's what I would of thought as well.

I am not using any threads. Well, I am using MSXML4 using smart pointers so I don't know what's going on in the background nevertheless the project was working just fine. I recently had a working project and decided that I wanted to clean up the code and reorganize the file structure. I added nothing new during this cleaning up process so it can't be anything I added.

I did things like:

Changed this from:

int A,R,G,B;

to this:

struct _Color
{
int A,R,G,B;
};

and

CString Fontname;
CString Fontstyle;
float Fontsize;
int A,R,G,B;

to

struct _Font
{
float Size;
CString Name, Style;
_Color Color;
};

I changed the way I included some of my file around and now the very first CString I get to I get the following error.

First-chance exception in HTPCCORE.exe (MFC42D.DLL): 0xC0000005: Access Violation.

crashing in the = operator

const CString& CString::operator=(const CString& stringSrc)
{
if (m_pchData != stringSrc.m_pchData)
{
crashs here-> if ((GetData()->nRefs < 0 && GetData() != _afxDataNil) ||

stringSrc.GetData()->nRefs < 0)
{
// actual copy necessary since one of the strings is locked
AssignCopy(stringSrc.GetData()->nDataLength, stringSrc.m_pchData);
}
else
{
// can just copy references around
Release();
ASSERT(stringSrc.GetData() != _afxDataNil);
m_pchData = stringSrc.m_pchData;
InterlockedIncrement(&GetData()->nRefs);
}
}
return *this;
}

Makes no sense.

If I were using threads what would the solution be. Oh, I am using VC++6 and I recently installed the latest service pack. Things were still working then as well.

John M. Drescher8-May-04 16:07

8-May-04 16:07

My thoughts are that you did not initialize something in your first version properly but you were lucky that it did not cause a problem.

John

Steve Messer8-May-04 18:02

8-May-04 18:02

That may be the case. I started a new empty project and slowly added in all my files and checking for things like uninitialized variables. It works fine again. I really did not change much beside using a new empty project. Thanks for your responses.

John M. Drescher7-May-04 10:29

7-May-04 10:29

smesser wrote:
So what is a good approach for separating common files like in my situation?

Exactly what you did. You can also seperate each part (execpt for the main application) into is own library or dll.

John

Steve Messer7-May-04 11:27

Context-sensitive modular HTML Help

7-May-04 11:27

The plugin is a dll I need to learn how to put common into a dll. Can you point out a good article?

Banister7-May-04 8:38

Banister

7-May-04 8:38

My help files are split in 4 .chm (one master, linking to others)... I want to search topic by ids without the user know that the topic doesn't come from the main .chm ?

I used
HtmlHelp(GetDesktopWindow(), HelpPath, HH_DISPLAY_TOC, id);
when I had only one .chm
but now I don't have an idea how to do the same!
thanks

D'Oh! | :doh:

C++ callback __cdecl to __thiscall

greg897-May-04 7:52

greg89

7-May-04 7:52

I am trying to wrap a C API in C++. The problem I am having is that some of the functions in this API are callbacks. When I create functions in a C++ class the calling convention is __thiscall. From each function I created I called the corresonding C function from the API. The problem is that the C function uses the __cdecl calling convention. I get an error when trying to compile

cannot convert parameter 2 from 'void *' to 'void (__cdecl *)(void *)'

Ex.
// this is the callback
void CTest:: Error(void *Param)
{
}

CNew new; // in the CTest class

new.AppCatchError(Error) //this is within the CTest class

void CNew::AppCatchError(void* HandlerFunc)// HandlerFunc a c++ member function
{
//this is the C API function
AppError(HandlerFunc); //error this is looking for a c function __cdecl
}

Maarten Kools7-May-04 8:00

7-May-04 8:00

If you pass a function pointer along with another function, you need to create a typedef of it's "signature" sorta say.

it'd be something like this:

typedef void (__cdecl *FuncPtr)(void *);

This basically defines a generic function signature, with C declaration and one void ptr argument.

And now use FuncPtr as argument for AppCatchError in order to be able to pass Error() along as a pointer.

Hope this helps.

If you're interested to know more about it, check this out

greg897-May-04 10:03

greg89

7-May-04 10:03

Still geting an error

cannot convert parameter 2 from 'void (__cdecl *(void))(void *)' to 'void (__cdecl *)(void *)'

This has to do with the fact that it is a member function. How does this work in C++, if this function was global function there wouldn't be a problem.

Maarten Kools7-May-04 10:12

7-May-04 10:12

You can do three things:

1) Make the function global
2) Make it static
3) Wrapper functions

John M. Drescher7-May-04 10:31

7-May-04 10:31

gs1589 wrote:
This has to do with the fact that it is a member function.

Yes, it does. If you want to use it this way the member function must be a static member function.

John

valikac7-May-04 18:51

valikac

7-May-04 18:51

Error(void *Param) is a member function. Make it static.

// this is the callback
static void __stdcall CTest:: Error(void *Param);

Kuphryn

NM_CUSTOMDRAW (ListView)

Maarten Kools7-May-04 7:22