[.net] COM, ActiveX, Windows Form, Web Browser [SOLVED]

Started by
11 comments, last by hellz 19 years, 8 months ago
[edit: this has been solved, see here and to a lesser extent, here, for the solution] OK, let's get straight to business. I'm adding a Quick Help Browser to my application. It's mixed managed and unmanaged C++ (I think the fact it's got some unmanaged code is irrelevent here). I've added a Microsoft Web Browser object to my form in the standard way (through the IDE). Now, it all compiles happily, and it gets to this line in the form's InitializeComponent() function:
this->QuickHelpBrowser = new AxInterop::SHDocVw::AxWebBrowser();
And it gives me:
Quote:An unhandled exception of type 'System.Threading.ThreadStateException' occurred in system.windows.forms.dll Additional information: Could not instantiate ActiveX control '8856f961-340a-11d0-a96b-00c04fd705a2' because the current thread is not in a single-threaded apartment.
Now, I'm not even really sure what a "single-threaded apartment" is. So basicly I have no idea where to start - as far as I can tell I need to turn my thread into a single-threaded appartment. The documentation I've found dosn't really help with managed C++ with forms. Any ideas? [Edited by - Andrew Russell on August 18, 2004 8:51:53 PM]
Advertisement
You can use an STAThread attribute, but read this page for "issues".

Alan
"There will come a time when you believe everything is finished. That will be the beginning." -Louis L'Amour
Additionaly, this is my entry point:

int APIENTRY _tWinMain(HINSTANCE hInstance,                     HINSTANCE hPrevInstance,                     LPTSTR    lpCmdLine,                     int       nCmdShow){	System::Threading::Thread::CurrentThread->ApartmentState = System::Threading::ApartmentState::STA;	Application::Run(new Form1());	return 0;}


So it's setting some kind of STA thing there... I'll try what AlanKemp just suggested in just a sec.
I'm not sure what the exact error means (it seem to be missing a few words), but the apartment threading model (single-threaded apartment) for COM objects (the threading model is determined by the COM object) means that the COM Object ensures thread safety by only allowing the client (your program) to make method calls from the same thread the object was created in.

Perhaps the error means the control is being initialized from a thread other then the one that created it.
A Single Threaded Apartment, basically means that when threads attempt to access a COM object, they have to access it sequentially. For example, say you have 3 threads that will at some point access one specific COM object. If they all try to access it at once, the first thread will gain access, finish what it's doing, and only at that point will the second thread be able to access the COM object. Then, once the second thread has finished, the third, and so on.

Multi Threaded Apartments on the other hand, allow simultaneous thread access to a COM object.

Hope that makes things a little clearer,

-hellz
OK, I couldn't get AlanKemp's thing to work.

You're probably on the right track, Michalson. I'm not sure though - does windows forms do anything in particular with extra threads?

In any case, I'm just going to quickly check up on what kind of threading this is doing. Any more help would be appreciated.

BTW, I checked the error and that is the complete text.
OK, on threads, This is the report from Process Explorer.

I've got the following thread start addresses:
mscoree.dll!CorExeMain
mscorwks.dll!CoInitializeCor+0x64a5
mscorwks.dll!CoInitializeCor+0x1780
mscorwks.dll!ReleaseFusionInterfaces+0x3fad9

That looks a lot like 4 threads to me. Not to mention two CoInitialize things, which sound like they could be causing a problem.

Of course, this is when it's paused in the debugger, so I'm not sure if that has any effect on things.

Additionally, .NET CLR Locks and Threads reports:
3 current logical threads
2 current physical threads
1 current recognized threads
1 total recogniszed threads

Anyway, perhaps there's some multi/single thread setting that I'm overlooking? Or is it something more sinister than that?

Cheers, AR

Andrew,

Perhaps this will help.

-hellz
OK folks, got somewhere at least. This is my new code:

__gc class AppFunctionClassThing{public:	static void MyAppMainFunction()	{		Application::Run(new Form1());	}};int APIENTRY _tWinMain(HINSTANCE hInstance,                     HINSTANCE hPrevInstance,                     LPTSTR    lpCmdLine,                     int       nCmdShow){	System::Threading::Thread::CurrentThread->ApartmentState = System::Threading::ApartmentState::STA;	System::Threading::ThreadStart* ts = new System::Threading::ThreadStart(0, &AppFunctionClassThing::MyAppMainFunction);	System::Threading::Thread* myappthread = new System::Threading::Thread(ts);	myappthread->ApartmentState = System::Threading::ApartmentState::STA;	myappthread->Start();	myappthread->Join();	return 0;}


This fixes the original problem but I still get an error:

Quote:An unhandled exception of type 'System.IO.FileNotFoundException' occurred in system.windows.forms.dll

Additional information: File or assembly name Interop.SHDocVw, or one of its dependencies, was not found.


When it tries to do this:
this->ResumeLayout(false);


I've got AxInterop.Shdocvw.dll in my working directory, perhaps the Ax in the filename is the problem or something strange. I'm willing to bet it's something stupid, but I'll muck around with it in the morning *yawn* Late night debugging != fun.

Thanks for the help chaps, AR
Also, my quick effort for a hackish fix produced this error instead:

Quote:An unhandled exception of type 'System.IO.FileLoadException' occurred in system.windows.forms.dll

Additional information: The located assembly's manifest definition with name 'Interop.SHDocVw' does not match the assembly reference.


When I just copied the file and renamed it without the Ax [smile]. I didn't think it would work.

This topic is closed to new replies.

Advertisement