events in multithreaded application

[Christopher Kimbell]

Hi,

I want to create a class that creates a thread internally to do some work.
It will interact with winforms using events.

What happens when the code that is running in a seperate thread raises an
event?
Will the code in the event handler that is attached to the event run in the
internal thread,
or will it run in the GUI thread?

The MSDN documentation says that all interaction with the GUI from other
threads have
to go through an Invoke method.
The user shouldn't know that the class used threads internally.


If anybody has any ideas, article links etc it would be most apreciated.

Thanks,

Chris

 

[100]

Hi Christopher,

What happens when the code that is running in a seperate thread raises an
event?
Will the code in the event handler that is attached to the event run in the
internal thread,
or will it run in the GUI thread?

It will run in the worker thread not in the UI thread.

The MSDN documentation says that all interaction with the GUI from other
threads have
to go through an Invoke method.
The user shouldn't know that the class used threads internally.

You cannot change the UI control form the thread that has not created the
control. But this is only for interacting with the UI controls (forms,
buttons, listboxes, etc). All other objects you can use from within whatever
thread you want as long as you take care of the sychornizations with the
other threads your thread may share serources with.

You can ofcourse understand whether you can tuch UI control directly or you
have to call Invoke. Poll the control's InvokeRequired property and if it is
true that means the call is has been made form thread different form the
thread created the control so control's Invoke method has to be used in
order to swithch the execution in the UI thread.
However, you cannot add control created from one thread to a form or control
created from another (the framework will throw an exception if you try).
Thus, you don't have to check InvokeRequired for all controls you want to
update in the event handler. You can check only with one of them (usually
the form) and call its Invoke method if necessary and then update all
controls you need.

HTH
B\rgds
100

 

[Christopher Kimbell]

Thanks for the information.

What I really wanted to do was to hide the fact that the class was
multithreaded.
Is there any way to marshall the event so that the class raises the event in
the worker thread,
but the event handler executes in the GUI thread?

The GUI just uses the object, it doesn't care how it is implemented.

Chris

 

[100]

Hi Christopher,
I'm afraid it is not possible unless you have a reference to one of the
controls in the UI thread.

B\rgds
100

 

[Christopher Kimbell]

Well that is just too bad, it would be a nice feature though.
Thanks for the help.

Chris

 

[100]

Hi Christopher,
You might have more then one UI thread how could you possibly know at which
thread context to execute the event handler. Further more, how I said the
events need to be executed by an UI thread only when the consumer wants to
tuch the UI how can you possibly know what I'm going to do in response to
the event. If all events were to be executed in an UI thread wouldn't it
defeat the idea of multithreading.

B\rgds
100

 

[Christopher Kimbell]

I see your point, thanks.

Chris

Hi Christopher,
You might have more then one UI thread how could you possibly know at which
thread context to execute the event handler. Further more, how I said the
events need to be executed by an UI thread only when the consumer wants to
tuch the UI how can you possibly know what I'm going to do in response to
the event. If all events were to be executed in an UI thread wouldn't it
defeat the idea of multithreading.

B\rgds
100

and