AFXEXT: Soap Opera Part 3
Matthias Bohlen -- MATTES@logotec.com
Wednesday, May 15, 1996
Hello,
thanks everyone for the info on avoiding resource id clashes in
different DLL's. This was the most important part of my problem.
> Mike: And that's why Matthais' solution isn't very good. He's
> protected every single function with activity that, with a little
> care, he could avoid completely. OK, I'll spend that "little care"
> on my projects, but what about the second half of my problem: the
> linker error messages?
OK, I'll spend that "little care" on my projects, but what about the
second half of my problem, the linker error messages?
Mike explained that normally, you won't have to switch module states
inside an MFC extension DLL:
> The article you quoted should have explained that the entry points
> in question come from outside of your modules. If your
> _AFXDLL-build MFC application is running and calls into an MFC
> extension DLL, MFC will maintain the module state for you. If some
> other module that is _not_ an MFC program or not an _AFXDLL-built
> MFC program calls into your DLL, you'll need to worry about managing
> the module state yourself.
Again thanks for this clear statement. But what if I will have the
rare case when I have to "worry about state switching myself" ?
When trying to call AFX_MANAGE_STATE( AfxGetStaticModuleState() )
from inside the extension DLL, I got really heavy linking problems:
> mfcs40d.lib(dllmodul.obj) : error LNK2005: __pRawDllMain already
> defined in DLLINIT.OBJ mfcs40d.lib(dllmodul.obj) : error LNK2005:
> _DllMain@12 already defined in DLLINIT.OBJ mfcs40d.lib(dllmodul.obj)
> : warning LNK4006: __pRawDllMain already defined in DLLINIT.OBJ;
> second definition ignored mfcs40d.lib(dllmodul.obj) : warning
> LNK4006: _DllMain@12 already defined in DLLINIT.OBJ; second
> definition ignored
These linking problems (as I have explained in the "soap opera"
message) come from two pRawDLLMain's (from MFC's DLLMODUL.CPP and
from AFXDLLX.H) and two DLLMain's (one from DLLMODUL.CPP, the other
from my own DLL initialization module).
How can I resolve these?
Best regards...
Matthias.
-------------------------------------------------------
Matthias Bohlen | Logotec Software GmbH
Phone: +49 228 64 80 520 | Chateauneufstr. 10
FAX: +49 228 64 80 525 | D-53347 Alfter, Germany
|
E-mail: mattes@logotec.com | CAD systems development
-------------------------------------------------------
Mike Blaszczak -- mikeblas@msn.com
Friday, May 17, 1996
---------
From: owner-mfc-l@netcom.com on behalf of Matthias Bohlen
Sent: Wednesday, May 15, 1996 01:51
> When trying to call AFX_MANAGE_STATE( AfxGetStaticModuleState() )
> from inside the extension DLL, I got really heavy linking problems:
>> mfcs40d.lib(dllmodul.obj) : error LNK2005: __pRawDllMain already
>> defined in DLLINIT.OBJ mfcs40d.lib(dllmodul.obj) : error LNK2005:
>> _DllMain@12 already defined in DLLINIT.OBJ mfcs40d.lib(dllmodul.obj)
>> : warning LNK4006: __pRawDllMain already defined in DLLINIT.OBJ;
>> second definition ignored mfcs40d.lib(dllmodul.obj) : warning
>> LNK4006: _DllMain@12 already defined in DLLINIT.OBJ; second
>> definition ignored
> These linking problems (as I have explained in the "soap opera"
> message) come from two pRawDLLMain's (from MFC's DLLMODUL.CPP and
> from AFXDLLX.H) and two DLLMain's (one from DLLMODUL.CPP, the other
> from my own DLL initialization module).
This isn't a linking problem: you've forced a reference to a routine (and
therefore, a library) that you shouldn't use in an MFC extension DLL. You
shouldn't call AfxGetStaticModuleState() in your MFC extension DLL. You can
call it in an MFC based EXE or in DLL linked statically with MFC.
In an extension DLL, you should only rarely need to protect external
functions, as I explained before. If you do decide you need the state
protection, you can implement it by finding a pointer to your module state
earlier in your DLL's execution with a call to AfxGetModuleState()... and then
storing that pointer someplace you can access in your DLL globally. Since
Win32 DLLs get per-instance data, this'll be just fine. If you look at the
MFC source code, you'll see another way to do it: manage a state all by
yourself after declaring it and initializing it explictily. See the source
for the individual DLL initialization routines, for example ... like
DLLOLE.CPP or DLLDB.CPP.
.B ekiM
TCHAR sz[] = _T("These words are my own.");
| Вернуться в корень Архива
|