Asynchronous Invoke and the UI thread (using delegates)

3 Mar 2006 10:59 AM

brisers

Hello,

After studying some of the available resouces
(
http://msdn.microsoft.com/msdnmag/issues/04/05/BasicInstincts/default.aspx) I
can see that it is forbidden to modify the UI directly from a secondary
worker thread. What I was wondering was whether I could instantiate a form
within my secondary thread, get some user input and carry on until I
finished? Does this break any rules of good programming conduct?

3 Mar 2006 12:00 PM

Armin Zingler

"brisers" <bris***@discussions.microsoft.com> schrieb
> Hello,
>
> After studying some of the available resouces
> (
> http://msdn.microsoft.com/msdnmag/issues/04/05/BasicInstincts/default.aspx)
> I can see that it is forbidden to modify the UI directly from a
> secondary worker thread. What I was wondering was whether I could
> instantiate a form within my secondary thread, get some user input
> and carry on until I finished? Does this break any rules of good
> programming conduct?

That's possible. The only condition: The Form must not have any relation to
Forms created in other threads.

Armin

3 Mar 2006 12:32 PM

Armin Zingler

Show quote Hide quote

"Armin Zingler" <az.nospam@freenet.de> schrieb
> "brisers" <bris***@discussions.microsoft.com> schrieb
> > Hello,
> >
> > After studying some of the available resouces
> > (
> > http://msdn.microsoft.com/msdnmag/issues/04/05/BasicInstincts/default.aspx)
> > I can see that it is forbidden to modify the UI directly from a
> > secondary worker thread. What I was wondering was whether I could
> > instantiate a form within my secondary thread, get some user input
> > and carry on until I finished? Does this break any rules of good
> > programming conduct?
>
>
> That's possible. The only condition: The Form must not have any
> relation to Forms created in other threads.

"no relation" does not mean, it mustn't have a reference, but there mustn't
be a child/parent/owner relation.

In the new thread you can write:

sub threadmain

application.run(new OtherForm)

end sub

The thread ends as soon as the Form is closed.

Armin

6 Mar 2006 2:26 PM

Brian Gideon

Armin,

No, I don't think it breaks any rules of programming conduct. The code
you provided will work fine provided that you understand that OtherForm
should remain completely independent from the other forms of your
application running on the main UI thread.

However, without knowning exactly what you're wanting to do I question
the need for another UI thread. Can't you collect all of the inputs
your worker thread needs before you start it? That way the worker
thread doesn't need any user interaction. The worker thread can use
Control.Invoke to marshal the execution of a delegate onto the main UI
thread as needed to communicate back to forms inside your application.

Brian

Armin Zingler wrote:
Show quoteHide quote

> "no relation" does not mean, it mustn't have a reference, but there mustn't
> be a child/parent/owner relation.
>
> In the new thread you can write:
>
>
> sub threadmain
>
> application.run(new OtherForm)
>
> end sub
>
> The thread ends as soon as the Form is closed.
>
>
> Armin

6 Mar 2006 3:08 PM

Armin Zingler

"Brian Gideon" <briangid***@yahoo.com> schrieb
> Armin,
>
> No, I don't think it breaks any rules of programming conduct. The
> code you provided will work fine provided that you understand that
> OtherForm should remain completely independent from the other forms
> of your application running on the main UI thread.

That's what I wrote.

> However, without knowning exactly what you're wanting to do

*I* don't want to do anything. :-)

Armin

6 Mar 2006 6:45 PM

Brian Gideon

Yeah, somehow I totally confused you with the OP. Sorry about that.
My post was not directed at you :)

Brian

Armin Zingler wrote:
Show quoteHide quote

> "Brian Gideon" <briangid***@yahoo.com> schrieb
> > Armin,
> >
> > No, I don't think it breaks any rules of programming conduct. The
> > code you provided will work fine provided that you understand that
> > OtherForm should remain completely independent from the other forms
> > of your application running on the main UI thread.
>
> That's what I wrote.
>
> > However, without knowning exactly what you're wanting to do
>
> *I* don't want to do anything. :-)
>
>
> Armin

6 Mar 2006 3:59 AM

Prester John

Add the following to your form and you can update its controls from another
thread:

CheckForIllegalCrossThreadCalls = False

Show quoteHide quote

"brisers" <bris***@discussions.microsoft.com> wrote in message
news:E8D8E52A-D461-4F77-837E-3DC7D5057A9E@microsoft.com...
> Hello,
>
> After studying some of the available resouces
> (
> http://msdn.microsoft.com/msdnmag/issues/04/05/BasicInstincts/default.aspx) I
> can see that it is forbidden to modify the UI directly from a secondary
> worker thread. What I was wondering was whether I could instantiate a form
> within my secondary thread, get some user input and carry on until I
> finished? Does this break any rules of good programming conduct?

6 Mar 2006 10:25 AM

Armin Zingler

"Prester John" <presterj***@comcast.net> schrieb
> Add the following to your form and you can update its controls from
> another thread:
>
> CheckForIllegalCrossThreadCalls = False

This doesn't solve the problem. It only makes the runtime ignores faults.

Armin