Get assertion failure in MFC Dialog-based app

We have a MFC dialog-based app which also supports COM automation.  The MFC wizard which created it placed the following line in the "DlgProxy.cpp" file:

      ASSERT (AfxGetApp()->m_pMainWnd != NULL);

The above line is in the CDlgProxy ctor, which seems to be a class used for automation support.

My problem is that when I run this application via OLE embedding, I get a failure on this line.

m_pMainWnd should be initialised in CMyApp::InitInstance() by the following code:

      CMyAppDlg dlg;
      m_pMainWnd = &dlg;
      int nResponse = dlg.DoModal();
      if (nResponse == IDOK)
              ....

 - but obviously the dialog is being created by some other class when the app is started by automation.

I have tried placing the following code in CMyAppDlg ctor:

    // Set myself as the main window if not done already
    if (theApp.m_pMainWnd == NULL)
    {
        theApp.m_pMainWnd = this;
    }

However I still get the assertion.

What is the correct way to avoid this assertion?
kbridgeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nicolay_ChCommented:
For what you use:
m_pMainWnd = &dlg;
??????

When you InitInstance terminating, m_pMainWnd you window still destroyed....
0
kbridgeAuthor Commented:
I set m_pMainWnd because this is a dialog-based app and I do want the dialog to be the main window for the application.  m_pMainWnd is used by other objects to determine which is the main window for the application.

I am aware that the dialog terminates when InitInstance terminates, but this is how dialog-based apps work.

Thanks for taking the trouble to look at my question anyway.
0
Nicolay_ChCommented:
Are you checked for call InitInstance in OLE embedding mode...
May be it not calling?
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Become a Certified Penetration Testing Engineer

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

eugene007Commented:
Is the theApp.m_pMainWnd a global variable.
0
Vinayak KumbarSr Program ManagerCommented:
Hi,

Ok, I have the dialog based app with automation enabled. Its comiling and running properly. I could not get ur line
>when I run this application via OLE embedding...

How I can run my exe using OLE embedding?

Thanks.
VinExpert
0
kbridgeAuthor Commented:
Hi VinExpert,

If you want to get OLE support for your exe, you can try the following:

1. Create a fresh app, using classwizard, and check OLE/COM support when prompted.  
2. Then create another one without OLE/COM checked.
3. Use WinDiff to check the differences between the two projects.  (Should only be the OLE/COM support bits.)
4. You can then manually add the OLE/COM support bits into your application.

0
kbridgeAuthor Commented:
Hi Nicolay_Ch,

I managed to solve the problem myself.  Actually what was happening was that there was some code further up in InitInstance which was causing it to return before executing the dialog creation code.  I have the following code in my InitInstance():

    if(cmdInfo.m_bRunStandalone)
    {
        // Not allowed to run standalone!
        // Print message and quit.
                    MessageHandler(MID_MAIN_APPSTARTFAIL);
        return FALSE;
    }


      CWCManagementDlg dlg;
      m_pMainWnd = &dlg;
      int nResponse = dlg.DoModal();

There was a problem with the setting of m_bRunStandalone attribute so that it was being set when the app was run via OLE embedding.  When I fixed that, the problem went away.
      
0
Nicolay_ChCommented:
Yea... It is...

In my servers I not give do this automatically...

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.