When you develop a Microsoft Foundation Classes (MFC)
regular dynamic link library (DLL), you may want to use object linking and
embedding (OLE) without exposing an OLE object, such as displaying a dialog box
from within the DLL that contains an OLE control. A failure may occur when you
call the
DoModal function in the dialog box creation if you used the
AfxOleInit or
AfxEnableControlContainer function to initialize OLE within the DLL. Typically, this is
done by calling the functions in the
InitInstance method of the
CWinApp derived class.
Back to the top
In a MFC regular DLL,
AfxOleInit does not initialize OLE because MFC cannot uninitialize OLE in
the DLL_PROCESS_DETACH method of the
ExitInstance function. In this case, OLE may already have been unloaded. The
decision to not initialize OLE is by design. The bug is that
AfxOleInit returns
TRUE after setting m_bNeedTerm to -1. According to the Visual C++
documentation, when
AfxOleInit returns
TRUE this means that OLE was initialized, and that is not the case in
a DLL.
Back to the top
In order to uninitialize OLE when it is initialized in the
DLL, this requires exported methods for initialization and uninitialization
that the client has to call because the uninitialization has to occur before
the
CWinApp::ExitInstance function, which is a part of DLL_PROCESS_DETACH.
A
better solution is to initialize and uninitialize OLE in the client
application. This can be done in MFC by calling
AfxOleInit in the application's
InitInstance method of the
CWinApp derived class. MFC then uninitializes OLE by exiting the
application.
Back to the top
Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the "Applies to" section.
Back to the top
