Problem using OCX in Mixed MFC & Managed App

[Werner]

Hello

I have a VC7 App consisting of "old" MFC-Source and new Manged Source that uses an OC
in one of its MFC-based dialogs
When started, AfxOleInit (called in InitInstance) fails with a message that "OleInitialize returne
scode RPC_E_CHANGED_MODE"
The documentation says

RPC_E_CHANGED_MODE
A previous call to CoInitializeEx specified the concurrency model for this apartment as multithread apartment (MTA).

I guess, that some CLR - related Code has done this (because the same App without /CLR-Optio
and managed Sources does not have this problem

If I comment out the OleInitialize in InitInstance, then the Message disappeares and all seem
to be OK until a MFC-based dialog which contains an OCX is created
At this point an assertion occurs in occmgr.cpp COccManager::CreateDlgControls at (Line 410

COleControlSiteOrWnd *pTemp =new COleControlSiteOrWnd(::GetDlgItem(pWndParent->GetSafeHwnd(),
pOccDlgInfo->m_pItemInfo[i].nId),pOccDlgInfo->m_pItemInfo[i].bAutoRadioButton)
ASSERT(pTemp->m_hWnd)
How can this problem be solved so that MFC-Source with Dialogs using OCXes can be mixe
with managed C++ source in one App

Thanks in advance for any hint .

Werne

[Gary Chang]

Hi Werner,

If I comment out the OleInitialize in InitInstance, then the Message disappeares and all seems
to be OK until a MFC-based dialog which contains an OCX is created.
At this point an assertion occurs in occmgr.cpp
COccManager::CreateDlgControls at (Line 410)
"
COleControlSiteOrWnd *pTemp =new
COleControlSiteOrWnd(::GetDlgItem(pWndParent->GetSafeHwnd(),
pOccDlgInfo->m_pItemInfo[i].nId),pOccDlgInfo->m_pItemInfo[i].bAutoRadioButto
n);
ASSERT(pTemp->m_hWnd);
"
The OleInitialize could not be commented out in InitInstance,and it is true
that your MFC ocx controls should be loaded in a STA thread.

I have a VC7 App consisting of "old" MFC-Source and new Manged Source that uses an OCX
in one of its MFC-based dialogs.
...
I guess, that some CLR - related Code has done this (because the same App
without /CLR-Option
and managed Sources does not have this problem.

Which project type of your VC7 application?
Based on your description, it appears that its main thread is a MTA thread
when complied as managed code, if so, how about call your MFC dialog(with
ocx control) in a child thread which resides in a STA?
Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

[Werner]

Hi Gary

thank you very much for your response
Here are the answers to your questions (and my new
questions resulting from your answers ..

Which project type of your VC7 application?
It is an MFC-EXE-App project, created with VC6 (dsw/dsp) and then automatically upgrade
by VS .NET 2003 to VC7 (sln/vcproj
Based on your description, it appears that its main thread is a MTA thread when complied as managed cod

My MFC source itself is not multithreaded; it never starts any child threads an
it never calls CoInitializeEx with COINIT_MULTITHREADED mode
so I don't know why the main thread is a MTA thread
does "/CLR" make it a MTA thread ?
or the usage of .NET Framework classes

Is it possible to make the main thread an STA thread again (as it was before I change
the project to "/CLR" mode and used .NET Framework classes) ?
If yes, how
if so, how about call your MFC dialog(with

ocx control) in a child thread which resides in a STA

how can this be done that my (complete) MFC-App-Source would ru
in a child thread which resides in a STA

Thanks in advance for your answers

Werne

[Gary Chang]

Hi Werner,

Thanks for the quickly reply!

After reviewing your messages carefully, now I can confirm the problem is a
known issue to the VS.NET 2003, you can find the resolution in the
following KB:

BUG: "HRESULT - 0x80010106" Error When You Run a Managed C++ Application
http://support.microsoft.com/?id=824480

However, for a MFC application, the managed entry point function should be
modified as:
//in Appname.cpp
...
#define _WIN32_WINNT 0x501 //for Windows2000, please use 0x0500
#include <objbase.h>
#include <stdio.h>

#using <mscorlib.dll>
using namespace System;

extern "C" void WinMainCRTStartup();

[System::STAThread]
int mymain() //the new entry point
{
//Initialize COM
HRESULT hr = CoInitialize(0);

//Initialize the CRT
WinMainCRTStartup();
//uninit
CoUninitialize();
return 0;
}
...

so I don't know why the main thread is a MTA thread;
does "/CLR" make it a MTA thread ?
or the usage of .NET Framework classes ? Please refer to the above KB.
Is it possible to make the main thread an STA thread again (as it was before I changedthe project to "/CLR" mode and used .NET Framework classes)? We don't recommend make the main thread an STA thread again, you can make
it an STA thread from the beginning, please check the KB.
how can this be done that my (complete) MFC-App-Source would run in a child thread which resides in a STA?

For the reason that your project is a MFC application project upgraded from
the VC6, you needn't take such an approach.
Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

[Werner]

Hi Gary

the code snippet from your last post inserted in my <Appname>.cpp solved the problem

Thank you very much

(I had searched the KB for this problem, but did'nt find KB 824480, because I searche
for RPC_E_CHANGED_MODE and AfxOleInit

Best regards

Werne