Does .NET have an equivalent Java AWT Thread?

[Guest]

Hi,

I am primarily a Java developer well versed in the ways of Java AWT and
Swing but am relatively new to .NET GUI development.

I've been making a simple windows application using C# that basically allows
a user to enter some data then submit it to be processed by a task running on
a separate thread. When the task is done the form gets updated showing some
results. The problem I'm running into is trying to update the GUI components
in a safe way so that only one thread is doing the update... in others words
a GUI thread.

In the world of Java this is pretty easy to do. One very simple way is for
the task in the non-GUI thread to create a new object that inherits the
java.lang.Runnable interface and post it on the AWT Event Queue via the
SwingUtilities.invokeLater() method. Once posted the AWT Thread will
eventually consume and run that object so that it can update the GUI safely.
(Also note that all user activity is run on the AWT thread too).

Basically what I want to know is if .NET has an equivalent well known GUI
thread like in Java where you can post task that will eventually be run to
update the GUI safely. I've been going through various .NET books and the
MSDN site to find information, but the only details I can get is to use
proper synchronization techniques. I'm very knowledgeable about how to
develop multi-threaded applications, but I find the lack of a well known GUI
thread to update the UI a bit frustrating.

Maybe I'm missing something and haven't come across the right information
yet, but any help would be greatly appreciated.

Thanks,

Michael Cohen
Oculus Info, Inc.

 

[Jon Skeet [C# MVP]]

<=?Utf-8?B?TWljaGFlbCBDT2hlbg==?= <Michael
(e-mail address removed)>> wrote:

Basically what I want to know is if .NET has an equivalent well known GUI
thread like in Java where you can post task that will eventually be run to
update the GUI safely. I've been going through various .NET books and the
MSDN site to find information, but the only details I can get is to use
proper synchronization techniques. I'm very knowledgeable about how to
develop multi-threaded applications, but I find the lack of a well known GUI
thread to update the UI a bit frustrating.

You don't post the event to a specific thread - you get a particular
control to invoke the delegate on the appropriate thread. Bear in mind
that there may be more than one UI thread.

See http://www.pobox.com/~skeet/csharp/threads/winforms.shtml

 

[Truong Hong Thi]

The .NET method most similar to SwingUtilities.invokeLater is
Control.BeginInvoke. For SwingUtilities.invokeAndWait, check out
Control.Invoke. Note that these methods invoke a delegate on the thread
that created the control, as Jon said, there is no single
event-dispatching thread.

Thi

 

[Nick Hounsome]

<=?Utf-8?B?TWljaGFlbCBDT2hlbg==?= <Michael
(e-mail address removed)>> wrote:



You don't post the event to a specific thread - you get a particular
control to invoke the delegate on the appropriate thread. Bear in mind
that there may be more than one UI thread.

Really?

How does that work then?

 

[Guest]

Thanks for the help. I looked into the Invoke and BeginInvoke methods for the
Control class. It seems messy compared to Java's GUI architecture, but what
can you do. For instance, to update mutliple controls you have to assign
individual delegates to each control to update their states. In Java with the
AWT event queue you simply have to post a single object on the queue that can
directly update the various controls without the need for delegates and async
callbacks. Having exclusive safe access to the GUI elements just makes things
easier. But if Microsoft decided to use delegates to update GUI controls
then, well, I guess that's what you have to use.

 

[Marc Gravell]

Are you sure about that? Generally (always?) all the controls on a Form will
be on the same thread - all you need to do is post a single call (that
internally updates multiple controls) to the Form's thread (.Invoke or
..BeginInvoke) and you should be sorted.

To my mind, event handlers are the ideal place to start switching thread -
simply for the reason that I know a delegate already exists, since I am
handling it - i.e.

private void SomethingClicked(object sender, EventArgs e) {
if(InvokeRequired) // talks to "this" - the Form
BeginInvoke(new EventHandler(SomethingClicked), sender, e);
else
UpdateLotsOfControls(); // could pass sender / e, but unlikely to be
useful in this specific case
}

 

[Nick Hounsome]

Thanks for the help. I looked into the Invoke and BeginInvoke methods for
the
Control class. It seems messy compared to Java's GUI architecture, but
what
can you do. For instance, to update mutliple controls you have to assign
individual delegates to each control to update their states. In Java with
the
AWT event queue you simply have to post a single object on the queue that
can
directly update the various controls without the need for delegates and
async
callbacks. Having exclusive safe access to the GUI elements just makes
things
easier. But if Microsoft decided to use delegates to update GUI controls
then, well, I guess that's what you have to use.

Since all the controls on a form will have been created by the same thread
it makes no difference which control you call BeginInvoke on and the single
delegate can update any or all of the controls - It is no different to the
java method except that it is an instance method rather than a class one.

 

[Jon Skeet [C# MVP]]

Really?

How does that work then?

Which bit? Having more than one thread? You can only have one thread
per *window*, but you could have multiple windows, each with their own
thread.

 

[Jon Skeet [C# MVP]]

Are you sure about that? Generally (always?) all the controls on a Form will
be on the same thread

Always - at least, you're not *meant* to have different threads
updating the same window.

 

[Marc Gravell]

Yeah, I thought so, but I had one of those self-doubt "is there some obscure
exception to this rule?" moments, and didn't want to state (as fact)
something that I was only 99.99985% certain of ;-p

Marc

 

[Nick Hounsome]

Which bit? Having more than one thread? You can only have one thread
per *window*, but you could have multiple windows, each with their own
thread.

Why would you do that and how does it work?

 

[Jon Skeet [C# MVP]]

Why would you do that

Sometimes it can make life easier, I believe. For instance, you might
want to have a splash screen in a different thread with a progress bar
at the same time as a form which *needs* to do a lot of work in its own
UI thread just to start up. You want the progress bar to be responsive
even while the main window might not be.

and how does it work?

How does it work internally? The different windows just have different
message pumps. What's not to work?

(I've a feeling modal dialog boxes may be somewhat "interesting" in
this scenario - haven't tried it.)

 

[Nick Hounsome]

Sometimes it can make life easier, I believe. For instance, you might
want to have a splash screen in a different thread with a progress bar
at the same time as a form which *needs* to do a lot of work in its own
UI thread just to start up. You want the progress bar to be responsive
even while the main window might not be.

I don't see how that helps - NO UI thread can do a lot of work because it
will hold up the display of its own UI elements even if it doesn't affect
any other.

I suppose that you could have a lot of virtually independent forms but where
would you put them all on the desktop and anyway that sounds more like a
multi-appdomain situation than a multi-form one.

How does it work internally? The different windows just have different
message pumps. What's not to work?
(I've a feeling modal dialog boxes may be somewhat "interesting" in
this scenario - haven't tried it.)

I also wonder why, if it is so useful, java just uses a single pump. It
can't be for technical reasons.

 

[Marc Gravell]

I use a form of this to interact (safely) with a particular ActiveX control
(specifically, the MapPoint desktop client). This control has a strong UI
element (mapping etc), but I use it essentially as a sync'd utility (except
that it is visible to the user); by dropping it onto a dedicated thread, I
can write sync'd methods that I can call from any other thread (it is an
expensive resource - you wouldn't want it open too many times), while
allowing the UI to display in parallel to my main UI - i.e.

Thread A (primary UI thread)
Thread B (dedicated mapping UI thread, STA)
A creates Thread W (worked thread doing something)
W talks to B (sync'd with any other Ws talking to B), with B and A both
fully responsive and visible to the user

Complicated: maybe. Effective: definately

Marc

 

[Jon Skeet [C# MVP]]

I don't see how that helps - NO UI thread can do a lot of work because it
will hold up the display of its own UI elements even if it doesn't affect
any other.

However, that's okay if the UI thread is just building the UI.

I suppose that you could have a lot of virtually independent forms but where
would you put them all on the desktop and anyway that sounds more like a
multi-appdomain situation than a multi-form one.

Well, it depends on why they're in different threads.

I also wonder why, if it is so useful, java just uses a single pump. It
can't be for technical reasons.

Well, not every windowing system uses the same one as Windows. If Java
had to be able to support a UI with multiple threads and found itself
running on a windowing system which didn't support that, there could be
trouble.

It's not useful very often, but it can be handy, that's all.