C / C++ / MFC

27-May-07 7:27

In Test.exe module the application class CTestApp was derived from CWinApp. Everything worked fine. Then I decided to move some common stuff from CTestApp to CCommonApp. This CCommonApp is defined in Util.dll module. Now CTestApp is derived from CCommonApp which is derived from CWinApp.

The contructor of CTestApp is called properly and all its parent contructors. However the application crashes right after this, because the AfxGetApp returns NULL in MFC core and can't call InitApplication method.

Any idea what can be the problem?

Thanks, Abyss

Mark Salsbery27-May-07 9:38

Mark Salsbery

27-May-07 9:38

You'll still need a global app object in the EXE project, something like:

// The one and only CTestApp object
CTestApp theApp;

If you already have that...

How is CCommonApp declared? It should be like this:

class AFX_EXT_CLASS CCommonApp : public CWinApp
{
...
};

Your DLL needs to be a legitimate MFC extension DLL as well.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Abyss27-May-07 10:00

27-May-07 10:00

Thanks for advice.

I have this global application object in EXE. My DLL is also a dynamic DLL, where the CCommonApp is exported using __declspec(dllexport) and imported in EXE using __declspec(dllimport).

I'm not sure what did you mean by legitime MFC extension DLL.
My Util.dll project has its own CUtilApp : CWinApp class, and _USRDLL define in project settings. Also tried to use DllMain method with _AFXEXT define. It did not help Frown | :-(

.

Maybe something is wrong with project settings, maybe something else. But I have no idea what could be wrong.

Thanks, Abyss

Mark Salsbery27-May-07 10:32

Mark Salsbery

27-May-07 10:32

Abyss wrote:
I'm not sure what did you mean by legitime MFC extension DLL.

See Extension DLLs[^]

Classes derived from MFC classes in a DLL and then derived from in an EXE means the DLL MUST
be an MFC extension DLL. MFC requires certain initialization in DllMain() and import/export
properties on classes must be dealt with. It's all documented at the link (and sublinks) above.

Also important - you can't statically link to MFC libraries - the DLL and the EXE need to use the
shared MFC DLL library.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Abyss27-May-07 18:48

27-May-07 18:48

Well, I tried to generate these two projects from scratch using VS Wizard. The EXE application is a simple MFC non doc-view architecture module. The DLL is a MFC Extension module. I added my CCommonApp class to the DLL and exported using AFX_EXT_CLASS macro. In EXE I replaced CWinApp with CCommonApp.

The result is the same Cry | :((

Now I would say that this is not supported. However I can remember that in the past I saw several projects where it worked well (unfortunately I can't find them)...

Any help is appreciated.

Thanks, Abyss

Abyss27-May-07 20:15

27-May-07 20:15

I found the culprit. My project is base on Multibyte character set. When I introduced the new DLL module it was set to unicode character set by default. And this caused the whole problem - different MFC libraries where linked to my modules. It was enough to switch the project to Multibyte char. set and it started to working.

It does not matter if the DLL is MFC Extension or Regular DLL. In both cases it works fine.

Thanks for your help.

Abyss

Re: Callback help needed [modified]

Mark Salsbery28-May-07 6:10

Mark Salsbery

28-May-07 6:10

Cool! Glad you found it! Smile | :)

Abyss wrote:
It does not matter if the DLL is MFC Extension or Regular DLL. In both cases it works fine.

It will probably matter eventually - the initialization in the extension DLL is important to many
of the MFC classes. It just depends which ones you use and where Smile | :)

The CWinApp class is one of
them - it's initialization in the DLL module is used with window/dialog creation for example.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Callback help needed

Thomas Andersen27-May-07 5:44

Thomas Andersen

27-May-07 5:44

Hi I'm trying to call a function in a DLL and am having trouble doing so because it uses callback and I need the function in the DLL to write to my dialog.

The function prototype is like this:

<br />
UINT CALLBACK PatchApply(LPSTR lpszCmdLine,LPVOID (CALLBACK *lpfCallBack)(UINT  Id, LPVOID lpParm),BOOL WaitFlag);

and the example given is in C and not C++ (i'm making a dialog based program in unmanaged VC++ 7

Example snippet :

<br />
typedef LPVOID (CALLBACK* PATCHCALLBACK)(UINT, LPVOID);<br />
<br />
UINT CALLBACK PatchApply( LPSTR CmdLine, <br />
			    PATCHCALLBACK CallBackFn, <br />
			    BOOL WaitFlag);<br />
<br />
LPVOID CALLBACK __export CallBack( UINT Id, LPVOID Parm );<br />

My callback function is declared as

LPVOID CALLBACK CallBack(UINT Id, LPVOID Parm);<br />

and in the callback program I try to write to a listbox on my dialog.

Prior to calling I do like this:

<br />
typedef LPVOID (CALLBACK* PATCHCALLBACK)(UINT, LPVOID);<br />
PATCHCALLBACK CallBackPtr;	<br />
CallBackPtr = MakeProcInstance((FARPROC) CallBack,  AfxGetInstanceHandle());<br />
<br />
nRetCode = PatchApply(lpszBuf, CallBackPtr, TRUE);<br />

The MakeProcInstance is also from example and I try to call the PatchApply function directly from the DLL as I link the lib file into my program.

I get this error "cannot convert from 'overloaded-function' to 'FARPROC'" with above code and don't know what to do

Can anyone tell med what I need to do to call this succesfully ?

Thanks

Richard Andrew x6427-May-07 7:24

Richard Andrew x64

27-May-07 7:24

Well, one thing is that FARPROC is defined as

typedef INT_PTR (WINAPI *FARPROC)(void);<br />

whereas your callback function has a return type of LPVOID.

So it looks like you're trying to redefine the return type of the callback function when you cast it to (FARPROC) in the call to MakeProcInstance.

Also, FARPROC has no arguments, so it is a very different function signature.

-- modified at 13:32 Sunday 27th May, 2007

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

vector::erase()

C_Zealot27-May-07 1:02

C_Zealot

27-May-07 1:02

Hi all:

My program crashed at the line:

for (vector<int>::iterator it = list.begin(); it != list.end(); ++it) {
if (*it < 0) list.erase(it);
}
//Filtering out all the negative numbers from a vector.

I am sure that it is vector::erase(it) is causing all the pain, but not sure how to fix.

Can anyone help?

Thank you

Cedric Moonen27-May-07 1:16

Cedric Moonen

27-May-07 1:16

When you call erase, it will invalidate your current iterator and all iterators that follow. Thus, when you erase something and try to increment this same iterator, this will cause an exception. The erase function returns an iterator to the next valid element, you need to use that.

Try to change your code to something like this:

while (it != list.end())<br />
{<br />
   if (*it<0)<br />
   {<br />
      it = erase(it);<br />
   }<br />
   else<br />
      it++;<br />
}

Cédric Moonen
Software developer

Charting control [v1.2]

C_Zealot27-May-07 1:21

C_Zealot

27-May-07 1:21

Thank you very much, it worked.

Garth J Lancaster27-May-07 1:28

Garth J Lancaster

27-May-07 1:28

Cedric's given you an answer, and its good that it works - here's another way - include <algorithm> and use remove_if ..

the following link shows how :-

http://support.microsoft.com/kb/156532[^]

'g'