0

I have a WinForms VB app, using Visual Studio 2010. I am using the WPF DocumentViewer, so it is hosted by the ElementHost control. In my AppMain_Form.Designer.vb, when the follopwing (generated) statement is executed:

Me.rv_doc_vwr_host = New System.Windows.Forms.Integration.ElementHost()

I get an exception (which I had to enable CLR exceptions for the debugger to get):

"The calling thread must be STA, because many UI components require this."

However, in my research for this problem, I found the following:

1) Windows Forms applications are SingleThreaded by default.

2) The Main procedure is generated automatically for Windows Forms applications, and it is hidden.

3) A Main procedure can be manually coded, but this requires disabling the Application Framework, which I believe is rather necessary for a Windows Forms application.

So, why is this exception occurring if the Windows Forms application is SingleThreaded by default? If not, how can I mark the Main procedure as STAThread if it is hidden? Why did I have to enable CLR exceptions to catch this? Prior to enabling CLR exceptions, this did not show up in my testing, but when I ran my app outside of Visual Studio, it displayed an exception box briefly about creating the main form, but before I could get any details it was replaced by my splash screen, then my main form. The app worked normally after that. However, I cannot deploy it with an exception message being displayed every time it starts up.

Radagast
  • 1
  • 1
  • It is a boilerplate WPF exception, it has nothing whatsoever to do with any Winforms code. it tries to detect that you are trying to access a WPF component (like ElementHost) on a worker thread. Which is invalid, WPF is not thread-safe. Be sure to know where it goes wrong, use Debug > Windows > Exception Settings and tick CLR exceptions if you don't know. And look at the Debug > Windows > Threads debugger window to find out what thread is doing the evil deed. You need to fix your exception handling as well, this is not the kind of mishap that should ever keep your program running. – Hans Passant Oct 15 '16 at 00:48
  • Thank you for your reply - it really helped! I didn't think of my app as multi-threaded, as I never explicitly create a thread. However, I looked at the Debug > Windows > Threads debugger window the next time I tested this (with CLR exceptions enabled) and sure enough, the current thread was a worker thread for my Splash screen. – Radagast Oct 16 '16 at 01:58
  • I am using the same form as my Help > About form, only the Help & Close buttons are not visible (they are mad visible after the main form is loaded. This form was setting a variable (in the FormShown event) to the main form to connect the Help window to when the Help button was pressed on the Help > About form. – Radagast Oct 16 '16 at 02:01
  • I didn't realize that that assignment was causing the main form to be created when the form was shown as a Splash screen. By moving that assignment to the Help button Click event (using a local variable, rather than a member variable), I avoided that early creation of the form and hence the exception! Thanks again! – Radagast Oct 16 '16 at 02:01

0 Answers0