Conference 7.286::visualc

1116.0. "Unicode DLL, Entry point symbol, ASSERT fails on AfxGetThread?" by TALLIS::NELSON (It's not the years it's the mileage!) Wed May 07 1997 11:39

	I've created a DLL which compiles and links just fine.  It's a unicode
DLL, as the rest of our applications and images are also unicode.


	I know in a regular app you have to set the Entry Point Symbol in
the Linker | Output tab to wWinMainCRTStartup, do you have to do something
similar for dll's?  I've looked all over.  Books online, MSDN, this notesfile
and VISUAL notesfile.  I can't find any mention.  It will compile and link
with either that edit set to blank or wWinMainCRTStartup.


	However, I get different results when using the DLL (both wrong),
which leads to my next question (if the answer to the first questions solves
this one, so much the better):  when the edit control Entry Point Symbol is
set to wWinMainCRTStartup, the dll fails to load.  I've stepped through the
code, and it fails on an ASSERT in appcore.cpp, line 90:

ASSERT(AfxGetThread == NULL);


	This is in the CWinApp::CWinApp function, very early on.  Now, if I
blank that edit control, then everything runs fine until I call the
constructor for the C++ class which resides in that dll (note that the main
entrypoint is not part of the C++ class, it's just an extern "C" function).


	This feels like a build problem more than a code problem, as I know
you can have MFC dll's called by MFC apps!  BTW, my little test app that I
wrote to test this dll is also MFC and unicode.  This is on Alpha, but I'll
bet my problem has nothing to do with the platform.  I can certainly post
the code if necessary, it's small.


	Any ideas?



Brian

    	I came across the need for all exported functions to use the
    AFX_MANAGE_STATE macro; unfortunately, adding this didn't help my
    problem.


    	However, it occurred to me that perhaps the problem is that both
    the dll class and the main app class are derived from CWinApp.  I think
    CWinApp::CWinApp is being called multiple times, once for the main app
    and again for the dll app.  I noticed that in the last call, when it's
    called from the dll, AfxGetThread is returning a value which
    corresponds to the main app thread.


    	Is it not possible to have an MFC dll and an MFC app call one
    another?  My guess is that there's a way to do it, but the answer is
    buried somewhere non-obvious.




    Brian