STAThread and windows form

  • Thread starter Thread starter Robert Scheer
  • Start date Start date
R

Robert Scheer

Hi.

The .NET documentation says the following about the STAThread
attribute:
"COM threading models only pertain to applications that use COM
interop. Using this attribute in an application that does not use COM
interop has no effect."

A windows form has this attribute on its Main method. Why? Can safely
I delete it from my form?

Does VB.NET use this attribute implicitly?

Thanks,
Robert Scheer
 
Inline ***

Willy.

Robert Scheer said:
Hi.

The .NET documentation says the following about the STAThread
attribute:
"COM threading models only pertain to applications that use COM
interop. Using this attribute in an application that does not use COM
interop has no effect."

A windows form has this attribute on its Main method. Why? Can safely
I delete it from my form?
Click to expand...

*** No. you shouldn't, Windows.Forms.Controls are simple wrappers for OS
provided controls and a lot of them are activeX (aka. COM) controls.
Does VB.NET use this attribute implicitly?
Click to expand...

*** Yes.
 
Willy Denoyette said:
Inline ***

Willy.



*** No. you shouldn't, Windows.Forms.Controls are simple wrappers for OS
provided controls and a lot of them are activeX (aka. COM) controls.
Click to expand...

Windows Forms controls are not ActiveX controls. VB6 had ActiveX versions of ListView, TreeView,
etc., but these were simply COM wrappers around the Windows controls. The .NET framework has .NET
wrappers around them instead.

You can, of course, use ActiveX controls in .NET. If you right-click your toolbox (in VS.NET), and
select Add/Remove Items..., and then choose an item from the COM Components tab, you will obviously
be using COM and would likely want the STAThread attribute. The Microsoft Web Browser control is
one of the most obvious ones you might use.

If you're not using any ActiveX controls or interopping with any other COM components, then yes, you
can safely remove this attribute.
 
Inline ***

SleazySt said:
Windows Forms controls are not ActiveX controls. VB6 had ActiveX versions
of ListView, TreeView,
etc., but these were simply COM wrappers around the Windows controls. The
.NET framework has .NET
wrappers around them instead.
Click to expand...

*** I'm sorry but you are wrong, the controls are activeX controls that are
wrapped by Winforms Control classes.
VB6 had no COM wrappers, ActiveX controls expose their functionality through
COM interfaces, ActiveX controls are (Single Threaded Apartment) COM objects
that implement some special interfaces.
But if you don't believe me just run ildasm on System.Windows.Forms.dll and
taka a look at the Control class (and other like Container).

You can, of course, use ActiveX controls in .NET. If you right-click your
toolbox (in VS.NET), and
select Add/Remove Items..., and then choose an item from the COM
Components tab, you will obviously
be using COM and would likely want the STAThread attribute. The Microsoft
Web Browser control is
one of the most obvious ones you might use.
Click to expand...
*** I know that, but that is not the point, the Windows controls are wrapped
by Windows.Forms, so Windows.Forms controls use COM under the covers, and
you better have STAThread set, or you are in for some weird blocking issues.
Think of this, if you wrap the MSFT Webbrowser control in a .NET class,
don't you think you need a STA thread to run an instance of that class?

Willy.
 
Willy Denoyette said:
Inline ***



*** I'm sorry but you are wrong, the controls are activeX controls that are
wrapped by Winforms Control classes.
VB6 had no COM wrappers, ActiveX controls expose their functionality through
COM interfaces, ActiveX controls are (Single Threaded Apartment) COM objects
that implement some special interfaces.
But if you don't believe me just run ildasm on System.Windows.Forms.dll and
taka a look at the Control class (and other like Container).
Click to expand...

Yes, you will find lots of ActiveX and COM stuff in the Control class. This is for two reasons.
One is to allow exposing a .NET control as an ActiveX control. The other is to facilitate wrapping
ActiveX controls in the .NET Control class. That doesn't mean that *every* Windows Forms control
uses ActiveX.

While ildasm is great, I recommend Reflector. Get it at http://www.aisto.com/roeder/dotnet/.

Whichever tool you use, though, with proper examination it's clear that Windows Forms controls do
not, on the whole, use ActiveX or any part of COM.

VB6 does indeed use COM wrappers. For instance, the ListView and TreeView controls are provided by
MSCOMCTL.OCX. This OCX is an ActiveX wrapper around the controls provided by COMCTL32.DLL. Note
that the "COM" in COMCTL32.DLL stands for "Common", not for "Component Object Model", and that this
DLL is not a COM component.

I programmed using straight C for a long time, Willy. I did not use COM (doing so is a huge
headache at best from C), and yet still managed to use all the standard Windows controls. The
Windows API has been around since long before ActiveX.
*** I know that, but that is not the point, the Windows controls are wrapped
by Windows.Forms, so Windows.Forms controls use COM under the covers, and
you better have STAThread set, or you are in for some weird blocking issues.
Think of this, if you wrap the MSFT Webbrowser control in a .NET class,
don't you think you need a STA thread to run an instance of that class?
Click to expand...

That was my point exactly, Willy. If you use a COM control, like the Web Browser control, you must
use the STAThread attribute. If you use standard Windows Forms controls, you do not need to use the
STAThread attribute.
 
Yes, you will find lots of ActiveX and COM stuff in the Control class.
This is for two reasons. One is to allow exposing a .NET control as an
ActiveX control. The other is to facilitate wrapping ActiveX controls
in the .NET Control class. That doesn't mean that every Windows Forms
control uses ActiveX.
Click to expand...

Agreed. Most WinForms controls simply wrap existing native controls, i.e.
a TreeView warsp the API directly, and does not use a class in an ActiveX.
While ildasm is great, I recommend Reflector. Get it at
http://www.aisto.com/roeder/dotnet/.
Click to expand...

Highly recommended, indeed.
Whichever tool you use, though, with proper examination it's clear that
Windows Forms controls do not, on the whole, use ActiveX or any part of
COM.
Click to expand...

Indeed. When I wrote a simple tool to use Grep and display the results in
a treeview, using comboboxes, buttons, check boxes, etc.etc., everything
worked well, until I tried to use the FolderBrowserDialog. It was simply
blank, until I discovered I had forgotten the STAThread.
 
a TreeView warsp the API directly
Click to expand...

wraps, not warsp, of course.
--
Rudy Velthuis

"I begin by taking. I shall find scholars later to demonstrate my perfect
right."
-- Frederick (II) the Great
 
It is also required for some OLE operations which have to happen from
the thread that initialized OLE. This includes interaction with the
clipboard, drag and drop, and, as Rudy pointed out, working with the
FolderBrowserDialog.

HTH,
 
Back
Top