Forum

Why my extension DLL initialize its own g_PaintManager, and than try use it not initialized? (application crashes sometimes).

SplitGUI.dll!CExtPaintManager::CExtPaintManagerAutoPtr::OnSettingChange()  + 0x40 bytes C++

SplitGUI.dll!CExtButton::OnSettingChange()  + 0x2f bytes C++

mfc80u.dll!CWnd::OnWndMsg(unsigned int message=, unsigned int wParam=, long lParam=, long * pResult=)  Line 2154 C++

pWndNotifySrc - is a one of CExtButton controls. Assert failed because g_PaintManager not initialized, m_pPaintManager is NULL. Question is why it didn’t initialized by main application.

Prof-UIS DLL is the same MFC Extension type of project as your DLL. Both EXE and your DLL depend on the Prof-UIS DLL. This means Prof-UIS DLL should automatically be initialized earlier then your DLL. The situation you described should never occur. But it can occur when loading your MFC extension DLL dynamically at early stage of EXE initialization (some constructor of global class variable) and if you used LoadLibrary() instead of AfxLoadLibrary(). If what we just guessed is not true, we need to ask you to create some test projects repeating the same situation and send it to us. Alternatively, we can connect to your desktop remotely and debug your extension DLL.

Now I moved all classes wich use profuis in a new MFC Extension DLL. ASSERT when change screen resolution or lock workstation gone. But it because now every extension DLL has own g_painManager. How it is possible? Now structure of my project is "Extension DLL 1 (some classes use profuis)", "Extension DLL 2 (some classes use profuis and depends on DLL1)", Main application (some classes use profuis and depends on DLL 1 and DLL 2). When I put breakpoint in CExtPaintManager::CExtPaintManagerAutoPtr::CExtPaintManagerAutoPtr() - I see three independent initialization of g_paintManager. Have you any suggestions?

If your extension DLL have multiple global paint managers, they they are MFC regular DLL’s - not MFC extension DLLs. But this configuration is also supported. Such regular DLLs should use both MFC and Prof-UIS as static libraries.
The MFC extension DLLs does now have theApp<code> global variable of <code>CWinApp-derived type. If all your DLLs are MFC extension DLLs, then you don’t need multiple paint managers and both EXE and all your DLLs will use the same one copies of MFC and Prof-UIS (this is the best configuration). So, please carefully check your DLL projects. Here is what you need to know:

http://msdn.microsoft.com/en-us/library/h5f7ck28(v=vs.80).aspx

If you need to load an extension DLL dynamically, then you should use the AfxLoadLibrary() MFC API instead of the LoadLibrary() Win32 API.

Nothing in LIB project settings. Prof-UIS.h included in stdafx.h both main project, and extension DLL.

All works fine, and looks like painted fine. One problem. When change screen resolution or lock workstation I get assert here:

void

Could you show a call stack listing? Which type of object is pWndNotifySrc?

We suspect your extension DLL was linked with some incorrect configuration of the Prof-UIS library. This can happen only if you specified LIB file of Prof-UIS library explicitly in your project settings. Prof-UIS is always linked automatically with your project. You need only to include the Prof-UIS.h header file into your project.