Re: Synchronizing dialog's from different threads
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 24 Jun 2009 10:23:55 -0700
On Wed, 24 Jun 2009 08:43:45 -0700, schaf <dlocke@xxxxxxxxxxxx> wrote:
Hi All!
I have a challenging task.
My app is split into two parts, a Base and a Main part.
Now I would like to create a controller class, which handles all
notifications (UI dialog similar to message boxes) from both parts.
The application contains multiple threads and therefore I need to
synchronize the creation of the notification to the main thread,
especially if I would like to handover the main UI-Handle to the
notification.show method.
But the first base function could send a notification before my main
UI is created. So I can not synchronize the notification to the UI
thread, neither by using Invoke nor by using the
SynchronizationContext. Is there a solution, where I can create a
SynchronizationContext for the main UI thread, before the UI creation
is finished?
Or is it not possible to synchronize such a behavior?
It really depends on your specific situation. You didn't provide any code, never mind a concise-but-complete example, so it's impossible to know for sure what would work best for you.
The main limitation on the SynchronizationContext is the same that exists for Control.Invoke(), which is that you need for there to be some kind of "dispatcher" running. Both Forms and WPF applications will have this going once the application is up and running (in Forms, for example, it occurs once the call to Application.Run() has been made, usually from the Program.Main() method).
You can emulate the same behavior yourself, but that would involve setting up a queue and a loop where you consume the elements of the queue, and then the thread that was executing that loop would never get around to starting up the UI. :) This is more appropriate for applications that need a similar behavior, but will never actually have a UI created.
It seems to me that the most obvious solution is to still make such a queue, but then simply consume the entire queue once the UI has been created. You could either make the queue special-purpose, queuing items only when you detect that the UI isn't present, or it could simply be part of your standard operating mechanism, where consumption of the queue continues to happen as the worker threads add new items during execution, even after the UI has first been created.
The queue itself could either be very specific to your application, with the elements being some data structure representing the work you want to present to the user, or it can be very general-purpose, simply containing delegates to be invoked during consumption.
If you want more specific advice than that, you'll have to be more specific about the question.
Pete
.
- References:
- Synchronizing dialog's from different threads
- From: schaf
- Synchronizing dialog's from different threads
- Prev by Date: Re: When to use delegates?
- Next by Date: Re: When to use delegates?
- Previous by thread: Re: Synchronizing dialog's from different threads
- Index(es):
Relevant Pages
|
