"David Ching" wrote:
I never understood when you export a class in an MFC Extension DLL, do you
have to call AFX_MANAGE_STATE at the top of every method? This is a real
pain. And in this case where you export a class derived from CDialog, the
entry point is DoModal(), which is in CDialog, and is not overridden in the
derived class, so how do you call AFX_MANAGE_STATE in this case?
Hi Stephen and David,
My understanding is that AFX_MANAGE_STATE is only necessary in _regular_ MFC
DLLs, not _extension_ DLLs. At any rate, I tried that, and I found it made
the linker complain about redefinition of _DllMain. Not sure why.
I did find the problem, though -- the application was actually calling a
function inside the DLL itself that was attempting to create and display the
dialog. I added the following:
HINSTANCE hInstOld = ::AfxGetResourceHandle();
::AfxSetResourceHandle (McfCoreDLL.hModule);
// Dialog stuff
::AfxSetResourceHandle (hInstOld);
to change the resource handle to that of the DLL, and it worked.
I'm not sure I understand why this was necessary though -- if I understand
the MSDN docs correctly, executables can use resources from extension DLLs
they've loaded without knowing in which module the resources are defined.
Tracing through the CDialog::DoModal code, I find
if (m_lpszTemplateName != NULL)
{
hInst = AfxFindResourceHandle(m_lpszTemplateName, RT_DIALOG);
HRSRC hResource = ::FindResource(hInst, m_lpszTemplateName, RT_DIALOG);
hDialogTemplate = LoadResource(hInst, hResource);
}
executed. I thought that AfxFindResourceHandle would return the handle of
the DLL, not the handle of the EXE, but it seems it's returning the handle of
the EXE.
Maybe someone at MSFT or more experienced with the inner workings of MFC
DLLs can shed some light on this.
Thanks,
Nick
I wonder if it's due to a non-unique resource ID. If m_lpszTemplateName is