DOCUMENT:Q161589  30-JUL-2001  [visualc]
TITLE   :DOC: AfxGetStaticModuleState() Causes Errors in an Extension DLL
PRODUCT :Microsoft C Compiler
PROD/VER:winnt:4.1
OPER/SYS:
KEYWORDS:kbdocfix kbdocerr kbDLL kbMFC kbVC410bug kbVC420fix kbGrpDSMFCATL

======================================================================
-------------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Visual C++, version 4.1 
-------------------------------------------------------------------------------

SUMMARY
=======

The Visual C++ version 4.1 MFC documentation indicates that MFC Extension DLLs
need to use the macro expression "AFX_MANAGE_STATE(AfxGetStaticModuleState());"
at the top of every exported DLL function. This is incorrect; MFC Extension DLLs
do not need to use this expression.

This error was fixed in the documentation for Visual C++ version 4.2 and later
versions of Visual C++.

MORE INFORMATION
================

Under the subheading "Extension DLLs" of the article "Visual C++ Books -> MFC
4.2 -> Programming with MFC:Encyclopedia - > Dynamic-Link Libraries (DLLs)
-> Dynamic-Link Libraries (DLLs)," the following text appears:

   "If you have a resource in your DLL, such as a dialog, you need to use the
   macro AFX_MANAGE_STATE to switch the MFC module state correctly, so that
   Windows looks in the DLL and not in the EXE for the resource. This can be
   done by adding the following line of code to the beginning of functions
   exported from the DLL:

      AFX_MANAGE_STATE(AfxGetStaticModuleState( ))"

This is incorrect. Extension DLLs do not need to add this macro at the top of
every exported function . The AFX_MANAGE_STATE macro can be used inside of
callbacks or custom window procedures to properly adjust the current module
state, but it should be used with AfxGetAppModuleState() or a specific module
state instance instead of AfxGetStaticModuleState().

Any attempt to use AfxGetStaticModuleState( ) in an Extension DLL will result in
possible run-time problems and the following linker errors:

   

   "mfcs40d.lib(dllmodul.obj) : error LNK2005: __pRawDllMain already
   defined in testdll1.obj
   mfcs40d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined
   in testdll1.obj
   mfcs40d.lib(dllmodul.obj) : warning LNK4006: __pRawDllMain already
   defined in testdll1.obj; second definition ignored
   mfcs40d.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined
   in testdll1.obj; second definition ignored"

The incorrect paragraph was removed from the documentation for Visual C++ in
version 4.2.

(c) Microsoft Corporation 1999, All Rights Reserved.
Contributions by Jason Strayer, Microsoft Corporation


Additional query words:

======================================================================
Keywords          : kbdocfix kbdocerr kbDLL kbMFC kbVC410bug kbVC420fix kbGrpDSMFCATL 
Technology        : kbVCsearch kbAudDeveloper kbVC410
Version           : winnt:4.1
Solution Type     : kbfix

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 2001.