How to properly create a CDialog box in a CWinThread derived class

0
votes

I have a MFC regular DLL project that worked fine under Visual Studio 2008, but when the project was upgraded to VS 2010, a new problem came up where the following assertion would fail in appcore.cpp: 

CWinApp::CWinApp(LPCTSTR lpszAppName)
{
    [...]
    ASSERT(AfxGetThread() == NULL);

The assertion would fail when more than one instance of the CDialog derived class was created. From the research I have done on the web, it seems there is change in the behavior of MFC which would cause this failure.

From what I have read, the workaround to this problem is to create each CDialog derived class in a new CWinThread, but I'm getting the same problem, so, I'm sure there is something missing in my implementation, however, I don't know what is missing.

An example I used to attempt to create a CDialog within a CWinThread class came from http://www.experts-exchange.com/Programming/System/Windows__Programming/A_1886-Create-a-Dialog-in-its-Own-Thread.html , however my code is still failing at the same above listed ASSERT.

So my question is, does anyone have a good example, with source, on how to properly create multiple CDialog derived classes, using CWinThread, in a MFC regular DLL?

Oh, and if my understanding of creating multiple threads to solve the above listed ASSERT is wrong, please tell me why.

1
c++visual-studio-2010dllmfc
Are you instantiating multiple CWinApp objects? – IInspectable
The ASSERT happens when a thread that was not created by the MFC and not prepared by the MFC uses one of the MFC functions.... The Problem of having code in a DLL is, that you donÄt know which threed is using the code. There is no Problem to Launch a MFC Thread and call DoMdal in the new thread. It will never ASSERT – xMRi
@xMRi Your description does not match the assertion. The assertion requires that AfxGetThread() returns NULL. – IInspectable
@IInspectableless, my original code was creating multiple CWinApp instances, and I have read online that doing so will cause problems. In my newer code, CWinApp appears to still be called multiple times, however, I noted one time that it didn't get ASSERT in the above listed line but instead failed elsewhere, which I cannot reproduce now. – AhiyaHiya
Oh! Sorry! But in this case, you created an additional CWinApp object! Why? Each exe has always only one CWInAp Object associated with the main thread. Each regular DLL may have one additional. You may have multiple CWinThread objects for each thread you created. CWinAp Objects are "per module singletons"... – xMRi

1 Answers

0
votes

Unfortunately, the answer to the problem actually involves the version of MFC being used. The DLL was using mfc10 whereas the host application was linked against mfc9; once the DLL was changed to use mfc9, the above listed problem went away.