Updating a windows forms control from a thread

  • Thread starter Thread starter DW
  • Start date Start date
D

DW

I've gotten this question a couple of times in interviews and I don't know
what they are looking for:

How do you update a control's property, such as a textbox.text property,
from a thread, in .NET? It seems to me you just update it normally. What
are the interviewers looking for here? Thanks.

- W
 
DW said:
I've gotten this question a couple of times in interviews and I don't know
what they are looking for:

How do you update a control's property, such as a textbox.text property,
from a thread, in .NET? It seems to me you just update it normally. What
are the interviewers looking for here?
Click to expand...

Always create your forms in your application's main UI thread. Instance
members of Windows Forms forms and controls are not safe for multithreading,
so accessing them directly can cause problems. In addition to that, your
forms need a message pump which is normally provided by the app's main UI
thread.

More information:

Multithreading in Windows Forms applications
<URL:http://dotnet.mvps.org/dotnet/faqs/?id=multithreading&lang=en>
 
Updating the GUI from a working thread is a big no-no...

(thats just me quoting someone here)


Picho
 
Thanks Picho. Then specifically, how would you do that? Could you provide
a small code example. I've been looking for one unsuccessfully. Thanks
again.

- DW
 
Well, I am no expert but...

I have this good book by Chris Sells - " Windows Forms Programming in C#".
there is a whole chapter discussing multi-threaded UI, and how shared data
is to be accessed using monitors.

personally (I might get banned from this group for my bad habbits...), I
usually raise events from the worker thread that have handlers in the UI
thread that reflects changes in the UI.

an example can be provided if you provide a skeletal context of your
specific problem.

Picho.
 
DW said:
Thanks Picho. Then specifically, how would you do that?
Click to expand...

'Control.Invoke'/'Control.BeginInvoke'. You'll find more information in my
other reply.
 
Herfried,

We have a problem based on updating the UI from worker threads..
Our app uses a docking style MDI UI, where each form is capable of receiving
updates from a central "controller", as well as performing form specific
tasks.
We use the Control.Invoke() lark, which of course works, but when we are
making updates to many forms (We could have a form showing a graph, one a
table, one a report etc.. all based on their own interpretation fo the data
being pumped out) we find that the UI becomes very slow, sticky and
unmanageable.

Is is possible to assign each form its own UI thread/message pump so they
can all act independantly of each other?


Steve
 
Theres no "in general" about it - it suggests there are situations where it is OK. Raising an event from the worker thread executes code on the worker thread that is part of the UI. YOU MUST NOT DO THIS. The mostr frustrating thing is that the WInforms classes don't tell you this ... until the next version, where in debug they will throw an exception.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Picho said:
Herfried what do you say about my event drivven solution?
Click to expand...

In general, event driven solutions are not thread-safe too, but this depends
on the implementation of the event. More information:

<URL:http://www.google.de/groups?selm=#XkWlYOuCHA.1656@TK2MSFTNGP09>
 
To my understanding, the non-thread-safe operations are the += and -= of the
event.
what if I make sure these only happen before I start the worker thread and
after it finishes working?
 
Back
Top