Hi All,
I have a big problem with STAThread attribute. I'm using XNA framework
connected with WinForms. XNA is working in non STAThread. I have a
problem with displaying CommonDialog forms e.g. OpenFileDialog. I
can't declare a main method as STAThread because of XNA framework. Is
there any way to declare form or some method in form as STAThread (I
think that a method from Form can invoke OpenFileDialog) maybe I'm
wrong.
Do you know how I can resolve a problem?
Thanks.
RK.
12  5050 
"rafalK" <kr*******@gmai l.comwrote in message
news:11******** *************@k 35g2000prh.goog legroups.com...
Hi All,
I have a big problem with STAThread attribute. I'm using XNA framework
connected with WinForms. XNA is working in non STAThread. I have a
problem with displaying CommonDialog forms e.g. OpenFileDialog. I
can't declare a main method as STAThread because of XNA framework. Is
there any way to declare form or some method in form as STAThread (I
think that a method from Form can invoke OpenFileDialog) maybe I'm
wrong.
Do you know how I can resolve a problem?
Thanks.
RK.
A Windows Forms application MUST be tagged with the STAThread attribute, no
way around this.
Not sure what you mean with "XNA is working in non STA Thread" though, do
you mean you are running XNA code in a separate thread, or are you running
XNA code on the main thread?
In the latter case, you simply need to add STAThread to your main entry, in
the first case you'll have to delegate the calls to the form by means of
Control.Invoke/BeginInvoke whenever you need to access the From or one of
it's elements.
Willy.
Willy Denoyette [MVP] <wi************ *@telenet.bewro te:
<snip>
A Windows Forms application MUST be tagged with the STAThread
attribute, no way around this.
Out of interest, what are the problems one might find without this? For
test purposes I've often created forms which do very little, and rarely
bothered to put the STAThread attribute on them. They've been fine -
but I quite understand that either this was through chance or because I
wasn't using particular components.
--
Jon Skeet - <sk***@pobox.co m> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
The only times I've needed it are when:
* using the Clipboard object
* using ActiveX controls / components
Other than that, I have never seen any issues in the wild when
omitting this...
Marc
I'm running XNA code in main thread and also Form is starting from
main thread. I'm working now without STAThread in main entry and it
works. But as I wrote some is not working. XNA (game library) can't
use STAThread declared in main thread because some components will not
work.
Do You know any way to get round problem ?
Use different threads for any code that /must/ be STA, and code that
/must not/ be STA?
Marc
"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...
Willy Denoyette [MVP] <wi************ *@telenet.bewro te:
<snip>
>A Windows Forms application MUST be tagged with the STAThread
attribute, no way around this.
Out of interest, what are the problems one might find without this? For
test purposes I've often created forms which do very little, and rarely
bothered to put the STAThread attribute on them. They've been fine -
but I quite understand that either this was through chance or because I
wasn't using particular components.
--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
A couple of the Windows Forms controls are simple wrappers around ActiveX
COM controls, notably all the "Dialog Controls" are AX control wrappers, one
of them being the OpenFileDialog as used by the OP.
Such controls need a *pumping* STA thread to run on.
Now, if you don't initialize your UI thread to enter an STA, the CLR will
initialize the thread to enter the MTA whenever you call into COM for the
first time, that is when you create an instance of say OpenFileDialog. Note
that the v2 SP1 CLR initializes the thread to enter the MTA (if not marked
otherwise) even before it starts the main thread.
FileDialog (the wrapped AX dialog) as all other dialogs, is marked as
requiring an STA, so it can't get instantiated on the calling MTA thread,
COM takes care of this by creating a new thread that gets initialized to
enter an STA and creates the instance of the dialog on this thread and
returns a proxy to the caller.
That mean you'll end with the following (important for this discussion)
threads in a Forms application that doesn't mark it's main UI thread as
STAThread.
Main thread (UI) MTA.
GDI Thread MTA (used by Forms)
STA thread created by COM hosting the FileDialog AX control.
So far so good, the control runs on a compatible thread, and the caller
receives a proxy (a marshaled Interface Pointer). The problem however is
that the STA thread created by COM on your behalf isn't pumping messages,
that means that your OpenFileDialog cannot communicate with the callers
thread. The result is that the dialog cannot be used,it will not even
show-up (I guess) and the UI thread deadlocks.
Note also that the Finalizer (MTA) thread cannot access the controls STA
thread whenever he needs to run the Control's Finalize method. This is no
big deal in this scenario, as the control is non-functional anyway, but it's
a big issue when you have to deal with non-visual AX controls.
Willy.
Willy Denoyette [MVP] <wi************ *@telenet.bewro te:
Out of interest, what are the problems one might find without this? For
test purposes I've often created forms which do very little, and rarely
bothered to put the STAThread attribute on them. They've been fine -
but I quite understand that either this was through chance or because I
wasn't using particular components.
A couple of the Windows Forms controls are simple wrappers around ActiveX
COM controls, notably all the "Dialog Controls" are AX control wrappers, one
of them being the OpenFileDialog as used by the OP.
Such controls need a *pumping* STA thread to run on.
Right. Okay, so in many cases you'd get away with it not entirely
through chance but just by not using the controls which require the
pumping STA.
Now, if you don't initialize your UI thread to enter an STA, the CLR will
initialize the thread to enter the MTA whenever you call into COM for the
first time, that is when you create an instance of say OpenFileDialog. Note
that the v2 SP1 CLR initializes the thread to enter the MTA (if not marked
otherwise) even before it starts the main thread.
Yikes - that sounds like a significant change. My understanding was
that the CLR would only initialize a thread one way or another the
first time a method with STAThread or MTAThread was encountered on that
thread. In other words, your Main method could call something else
which in turn was decorated with STAThread. Am I right in interpreting
your comments to say this isn't the case with the v2 CLR SP1?
FileDialog (the wrapped AX dialog) as all other dialogs, is marked as
requiring an STA, so it can't get instantiated on the calling MTA thread,
COM takes care of this by creating a new thread that gets initialized to
enter an STA and creates the instance of the dialog on this thread and
returns a proxy to the caller.
That mean you'll end with the following (important for this discussion)
threads in a Forms application that doesn't mark it's main UI thread as
STAThread.
Main thread (UI) MTA.
GDI Thread MTA (used by Forms)
STA thread created by COM hosting the FileDialog AX control.
Why is the GDI thread not the main thread? I thought that
Application.Run just ran the message pump on the current thread? Or
does GDI just need two threads anyway, one for message pumping and one
for something else?
So far so good, the control runs on a compatible thread, and the caller
receives a proxy (a marshaled Interface Pointer). The problem however is
that the STA thread created by COM on your behalf isn't pumping messages,
that means that your OpenFileDialog cannot communicate with the callers
thread. The result is that the dialog cannot be used,it will not even
show-up (I guess) and the UI thread deadlocks.
Note also that the Finalizer (MTA) thread cannot access the controls STA
thread whenever he needs to run the Control's Finalize method. This is no
big deal in this scenario, as the control is non-functional anyway, but it's
a big issue when you have to deal with non-visual AX controls.
Right. Thanks for clearing that up. Admittedly it's open up other cans
of worms in terms of my understanding of WinForms, but there we go...
--
Jon Skeet - <sk***@pobox.co m> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...
Willy Denoyette [MVP] <wi************ *@telenet.bewro te:
Out of interest, what are the problems one might find without this? For
test purposes I've often created forms which do very little, and rarely
bothered to put the STAThread attribute on them. They've been fine -
but I quite understand that either this was through chance or because I
wasn't using particular components.
A couple of the Windows Forms controls are simple wrappers around ActiveX
COM controls, notably all the "Dialog Controls" are AX control wrappers,
one
of them being the OpenFileDialog as used by the OP.
Such controls need a *pumping* STA thread to run on.
Right. Okay, so in many cases you'd get away with it not entirely
through chance but just by not using the controls which require the
pumping STA.
If you only use controls that are *not* COM based, *and* If you don't use
"cust and paste" support in Windows Forms, which is OLE based (OLE is a COM
based technology), then you can safely ignore the STAThread attribute on
main, but why would you?
The problem is that you can't possibly know which controls are COM based and
which are not, so STATHread is a safe bet when you have to deal with Forms
and V3's WPF.
>Now, if you don't initialize your UI thread to enter an STA, the CLR will
initialize the thread to enter the MTA whenever you call into COM for the
first time, that is when you create an instance of say OpenFileDialog.
Note
that the v2 SP1 CLR initializes the thread to enter the MTA (if not
marked
otherwise) even before it starts the main thread.
Yikes - that sounds like a significant change. My understanding was
that the CLR would only initialize a thread one way or another the
first time a method with STAThread or MTAThread was encountered on that
thread. In other words, your Main method could call something else
which in turn was decorated with STAThread. Am I right in interpreting
your comments to say this isn't the case with the v2 CLR SP1?
The current version of the CLR initilizes COM at the first call into a RCW,
say from the main UI thread. If the main entry is not tagged with a thread
attribute, the RCW will initialize the thread to enter the MTA, else it will
initialize the thread to enter the apartment that is specified by the
attribute.
The problem with the current version is that initializing at first call
might be too late , therefore the CLR team took the decision to initialize
the thread before calling main. That means that the UI thread is always
initialize when main starts executing, and there is no surprise here,
STAThread initializes the thread to enter an STA, all other cases initialize
the thread to enter the MTA.
>FileDialog (the wrapped AX dialog) as all other dialogs, is marked as
requiring an STA, so it can't get instantiated on the calling MTA thread,
COM takes care of this by creating a new thread that gets initialized to
enter an STA and creates the instance of the dialog on this thread and
returns a proxy to the caller.
That mean you'll end with the following (important for this discussion)
threads in a Forms application that doesn't mark it's main UI thread as
STAThread.
Main thread (UI) MTA.
GDI Thread MTA (used by Forms)
STA thread created by COM hosting the FileDialog AX control.
Why is the GDI thread not the main thread? I thought that
Application.Run just ran the message pump on the current thread? Or
does GDI just need two threads anyway, one for message pumping and one
for something else?
GDI creates and manages it's own thread, this is not a CLR thread , it
becomes a CLR thread when this thread calls back into the main thread.
>So far so good, the control runs on a compatible thread, and the caller
receives a proxy (a marshaled Interface Pointer). The problem however is
that the STA thread created by COM on your behalf isn't pumping messages,
that means that your OpenFileDialog cannot communicate with the callers
thread. The result is that the dialog cannot be used,it will not even
show-up (I guess) and the UI thread deadlocks.
Note also that the Finalizer (MTA) thread cannot access the controls STA
thread whenever he needs to run the Control's Finalize method. This is
no
big deal in this scenario, as the control is non-functional anyway, but
it's
a big issue when you have to deal with non-visual AX controls.
Right. Thanks for clearing that up. Admittedly it's open up other cans
of worms in terms of my understanding of WinForms, but there we go...
Well, I guess it's just a matter of respecting a number of simple rules
(this is in general what Software development is all about), if you don't
then you better know what's going on under the covers.
Willy.
Willy Denoyette [MVP] <wi************ *@telenet.bewro te:
Right. Okay, so in many cases you'd get away with it not entirely
through chance but just by not using the controls which require the
pumping STA.
If you only use controls that are *not* COM based, *and* If you don't use
"cust and paste" support in Windows Forms, which is OLE based (OLE is a COM
based technology), then you can safely ignore the STAThread attribute on
main, but why would you?
In my case it's simply been forgetfulness for throwaway apps.
The problem is that you can't possibly know which controls are COM based and
which are not, so STATHread is a safe bet when you have to deal with Forms
and V3's WPF.
Fair enough.
Yikes - that sounds like a significant change. My understanding was
that the CLR would only initialize a thread one way or another the
first time a method with STAThread or MTAThread was encountered on that
thread. In other words, your Main method could call something else
which in turn was decorated with STAThread. Am I right in interpreting
your comments to say this isn't the case with the v2 CLR SP1?
The current version of the CLR initilizes COM at the first call into a RCW,
say from the main UI thread. If the main entry is not tagged with a thread
attribute, the RCW will initialize the thread to enter the MTA, else it will
initialize the thread to enter the apartment that is specified by the
attribute.
The problem with the current version is that initializing at first call
might be too late , therefore the CLR team took the decision to initialize
the thread before calling main. That means that the UI thread is always
initialize when main starts executing, and there is no surprise here,
STAThread initializes the thread to enter an STA, all other cases initialize
the thread to enter the MTA.
Hmm... that still sounds like a breaking change where previously you
might have had:
Main (no attribute) calling...
StartUI (STAThread) calling...
OtherStuff
I *think* that would have previously used an STAThread, but is now
using an MTAThread (and is therefore incorrect). Or am I just wrong
about it previously using an STAThread in that case?
Main thread (UI) MTA.
GDI Thread MTA (used by Forms)
STA thread created by COM hosting the FileDialog AX control.
Why is the GDI thread not the main thread? I thought that
Application.Run just ran the message pump on the current thread? Or
does GDI just need two threads anyway, one for message pumping and one
for something else?
GDI creates and manages it's own thread, this is not a CLR thread , it
becomes a CLR thread when this thread calls back into the main thread.
Blick. Hopefully Joe Duffy's new book will explain all this when it
comes out :) I'm woefully uninformed when it comes to WinForms
threading. General threading principles I'm fine with, but this is
somewhat different.
Right. Thanks for clearing that up. Admittedly it's open up other cans
of worms in terms of my understanding of WinForms, but there we go...
Well, I guess it's just a matter of respecting a number of simple rules
(this is in general what Software development is all about), if you don't
then you better know what's going on under the covers.
True.
--
Jon Skeet - <sk***@pobox.co m> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: sonu |
last post by:
Hi
I have developed a smart client application. When i try to
execute it. It displays the first form which is the login
screen. On giving the corrent login id and password, the
main form opens. It has 2 menus. On clicking the submenu,
it throws an STAThread exception. The error details are
given below. I have included
System.Threading.Thread.CurrentThread.ApartmentState =
|
by: warren |
last post by:
Hello,
Anyone can brief me what is this in front of the Main method
for?
and when must it be there, and when is it optional?
thank you.
|
by: Justine |
last post by:
hi all,
i just want to know the significance of in
the C# application. Why & for What reason is this used.
Thanz in Advance,
Justine
|
by: |
last post by:
Hi All,
I have allready tried to ask a similar question , but got no answer until now. In the meantime, I
found, that I cannot understand some thread-settings for the Main() function
.
If I use the attribute for the Main() function, I get "access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how possibly can
explain why this happens?? If I remove this...
|
by: Alberto |
last post by:
What's the meaning of the STAThread attribute?
Thanks
| | |
by: Tom |
last post by:
Do we need to put the STAThread attribute on our Sub Main anymore if we are
using the 1.1 Framework? See some YEAs and NEAs when searching on Google so
thought I would ask here.
Tom
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
| | |
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
