non-control-based communication from worker threads to UI thread

[Tim Crews]

Hello:

I have an application that consists of a UI thread and several worker threads.
There is no top-level form that can be counted on as always present. (This is
a kiosk application whose user interface consists of a series of independent
screens, sort of like a slide show.) However, the worker threads detect
several conditions that require the UI thread to close the current form and
display a new form.

So, I need a persistent destination in the UI thread for messages that are sent
from the worker threads. The only provision I am aware of for communication
from a worker thread to the UI thread is the Control.Invoke function and its
cousins, inherited from the ISynchronizeInvoke interface. Since none of the
application's visible forms are persistent, none of them are candidates as the
Control to use for this call. So, currently, I am considering an
implementation that involves an always-present, non-visible form that has a
variety of member functions that can be Invoked from the worker threads. This
form then makes calls into the application classes that maintain the
application state and determine which visible form to display next.

This seems like a kludge to me. Is there a more general way for a worker
thread to invoke functions in the context of the UI thread, without using a
dummy form/control to make it happen? Is there another way to get my Executive
class (the one that maintains application state and knows which forms to
display) to benefit from the ISynchronizeInvoke interface and participate in
the message dispatch loop that is running in the UI thread? Is there an
example of a general design pattern for this kind of communication that you can
point me to? All of the online examples I have seen are simpler than my
application, since they always involve only a single persistent Form.

Thank you for any advice,

Tim Crews,
GECO, Inc

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hello Tim,

I'm afraid that there's no other way than using a dummy invisible control.
At least this approach worked just fine for me when I needed advanced
multi-threading in a VS .NET add-in.
You can experiment with PostThreadMessage API, but this solution looks much
more cumbersome to me.

 

[Ian Griffiths [C# MVP]]

Unfortunately, the hidden form approach you describe is the right one.

This is because in principal, there may be multiple UI threads. Windows
Forms supports the model where each top level window may have its own
thread. (The same model Internet Explorer uses.) So although in most UI
applications, it makes sense to talk about "The UI Thread" there are some
applications where there are multiple UI threads.

So you need some kind of context indicating which particular UI thread you
would like to send the message to. The only supported context for this is a
Control of some kind - there's nothing in the Windows Forms api that
represents a particular UI thread.