Using AFX_MANAGE_STATE

I've a MFC extension DLL.
My question is that when all i need to call AFX_MANAGE_STATE( AfxGetStaticModuleState());

I suppose, it needed to be called while Creating (initializing) the resources. e.g Functions which creates Dialog, Icon, Bitmap (or whatsoever in the DLL resource file)

The KB Article says that we only need to call this inside the callbacks and windows procedures instead of putting in all exported functions

Currently I put the manage state code in the functions which deals with resources. Am I correct or not Do I need to limit the usage of managing state to the resource creation(initialization) process

Could you please put some light on this

Answer this question

Using AFX_MANAGE_STATE

Iggy2
You need it whenever you are called from non-MFC code. I'd play it safe and place them on all DLL exports and Win32 API callbacks (don't assume that this only has to do with Win32 resources.)
Gy&#240;a
I take that back: DllMain is defined on an MFC Extension DLL. MFC DLL's define _AFXDLL, and MFC Extension DLL's define _AFXDLL and _AFXEXT, and hence both link against mfcs80xx.lib which contains the stock DllMain. The linker should be using DllMain and ignoring the one in mfcs80xx.lib. I don't know why you're having a problem, but regardless the solution is to generate a new Extension DLL from scratch and compare or migrate code over.

I cannot reproduce the link error in the presence of AFX_MANAGE_STATE(AfxGetStaticModuleState()); so I cannot help you there.

You could run into issues with CString between MFC modules, but I normally would not advise exporting functions that take any sort of C++ class because of versioning problems.

There are newsgroups dedicated to MFC in the MSDN discussion group area. Have you tried there I quit MFC programming long ago.

Brian
J.Mathes
I believe DllMain is in the static MFC library you link in. I would recreate an MFC Extension DLL that does compile and compare your project settings and code.

I don't understand the last question. As long as your char strings and wchar-strings are not going through an unsafe cast (which could be the case when you call an DLL function with the wrong character width), there should not be a problem on this DLL boundary. I don't understand the part of resources here.
CSharpShooter

Brian,

Thanks for the reply. I think the error will be spawned even if we are calling/ using the exported classes or interface from the DLL from a MFC application. especially while the calling appilcation and the DLL has resource having same values.

When I compiled the code after adding AFX_MANAGE_STATE(AfxGetStaticModuleState()); inside the exported functions(even tried with the dialog classes of the DLL), it created some linking errors like

error LNK2005: _DllMain@12 already defined

etc....

I just referred the following discussion on code guru. http://www.codeguru.com/forum/archive/index.php/t-78673.html

But I could not resolve the issue without commenting out the DLLMain function. Could you please help me in this regard

I'm using MFC Extension DLL.

One more doubt I've is that, if the calling application is Non-Unicode Build and the DLL built with UNICODE, is there any chance for not creating the resources

gabriel_333

Brian Kramer wrote:

I don't know why you're having a problem, but regardless the solution is to generate a new Extension DLL from scratch and compare or migrate code over.

I cannot reproduce the link error in the presence of AFX_MANAGE_STATE(AfxGetStaticModuleState()); so I cannot help you there.

Brian,

I've tried the code with Visual C++ 7.1 and 6.0 but not with Visual C++ 8.0

In both VC++ 6 & 7 I could reproduce the code but my Build environment is Visual C++ 6.0

I think it is possible to reproduce by adding a new MFC Extension DLL and use the AFX_MANAGE_STATE code in any of the exported functions. I could reproduce it here.

Brian Kramer wrote:

MFC DLL's define _AFXDLL, and MFC Extension DLL's define _AFXDLL and _AFXEXT, and hence both link against mfcs80xx.lib which contains the stock DllMain

Is there any problem in using the stock DLLMain (commenting out my DLLMain since I'm not doing any specific initialization (except some MFC Initializations)

I shall also try with MFC News Group.

Kamii47
Brian,

Actually there are some issues with a MFC extension DLLs I'm using.

My questions are
1. Will it be a problem if the extension DLL not having a DLLMain function (comment out it)

2. Is there any method to resolve the linking errors occur while we put AFX_MANAGE_STATE(AfxGetStaticModuleState()); without commenting the DLLMain function

3. Is it an issue if I call a MFC DLL Linked with UNICODE Library and the caller application is a Non-Unicode one

Seems my problem has a solution in MSFT KB. But it seems pretty difficult than commenting out DLLMain :)

The fact is that I still can access the resources and exported functions from the DLL without having any problem after commenting out the DLLMain.
Is it a standard and preferable way
Jakobdo
I would use your own DllMain for MFC extension DLLs. Resolving the subsequent linker error should be your focus, and I would proceed by comparing your project against one generated by the wizard.
Using AFX_MANAGE_STATE

Answer this question