[STAThread]???

  • Thread starter Thread starter SSP
  • Start date Start date
S

SSP

I don't get it??

Until few minutes I debugged my forms and it worked like a breeze...no
problems.

Then suddenly I started getting a totally unrelated error message like:

"DragDrop registration failed"

After a fuming for a few minutes I discovered that it needed "[STAThread]"
stuff ahead of calling the Main method.

I am new to windows forms (primarily a web developer)...I don't understand.
Why did it start to appear all of a sudden? What the h*** does it do??

SSP
 
SSP said:
I don't get it??

Until few minutes I debugged my forms and it worked like a breeze...no
problems.

Then suddenly I started getting a totally unrelated error message like:

"DragDrop registration failed"

After a fuming for a few minutes I discovered that it needed "[STAThread]"
stuff ahead of calling the Main method.

I am new to windows forms (primarily a web developer)...I don't understand.
Why did it start to appear all of a sudden? What the h*** does it do??
Click to expand...

It basically makes sure that the COM apartment threading model is the
Single Threaded Apartment model. The first time any method with the
[STAThread] or [MTAThread] attribute is called on any particular
thread, that threading model is set up for that thread. Lots of
controls require the STA mode, so basically all Windows Forms programs
are likely to have that attribute on their Main method (or somewhere
similar).

I don't know many details about this - such as whether you can have
some threads in STAs and others in MTAs.
 
All windows controls have thread affinity and so must be called from the
same thread in which they were created. Therefore when you register a
control for drag and drop it will throw an exception if it is in the MTA
(multi threaded apartment) because in the MTA the call could be coming from
any random RPC thread. Therefore you need to mark your main thread as STA as
thats where you are creating your GUI controls. If you do not mark your
thread with STAThread then the first time it needs to use COM is will
default to adding itself to the MTA.

Hope that helps,
Phil.
DotNetMagic
 
Hmm, good info -- I never knew exactly what that was for either.

So if I wanted to start a secondary UI thread with its own message pump,
and if that secondary thread used COM stuff like the clipboard or any
common controls, then I would probably need [STAThread] somewhere along
the line, right? Would it be best to put that attribute on the method
that's referenced by the ThreadStart or WaitCallback delegate?
 
Joe said:
So if I wanted to start a secondary UI thread with its own message pump,
and if that secondary thread used COM stuff like the clipboard or any
common controls, then I would probably need [STAThread] somewhere along
the line, right? Would it be best to put that attribute on the method
that's referenced by the ThreadStart or WaitCallback delegate?
Click to expand...

I think you would set Thread.ApartmentState before starting the thread
 
Back
Top