There are several ways of doing that.You can use OccationalConsumerOf<T>, but that is really for special cases.
The way I would recommend to do it would be: a/ you publish a message to the bus from the UI b/ you have separate consumers that accept messages from the bus and decide what needs to be done with it. As a good example, you aren't necessarily going to want to update the same form that generated it. I usually do it in two modes, the consumer does whatever works needs to be done on a background thread, then publish an event (locally in the application using event aggregator) that the forms can subscribe to. This create strong separation between UI actions and background actions, this is important for creating responsive application. On Wed, Oct 7, 2009 at 5:05 PM, Jason Meckley <[email protected]>wrote: > > The applications I develop are web-based. I have not had to directly > deal with threading at the GUI level with asp.net. I got around to > spiking a desktop app and passing work to background threads. nothing > fancy, just ThreadSlee(5000); return DateTime.Now.ToString("F"); > > My first spike used ISynchronizeInvoke. I came to this solution by > getting the classic cross threading exception and following MSDN help > links. I can up with a solution, but didn't care for it to much. I > also remember reading that ISynchronizeInvoke is good for small > updates to a control or two, but it's not recommended for large UI > updates. I thought I remember Udi stating that in a podcast. > > My second spike was taken from Jeremy's lastest MDSN article > http://msdn.microsoft.com/en-us/magazine/ee309512.aspx where he uses > the SynchronizationContext. I got this working and I must say I really > like it. > > Somewhere in this forum's archive I have a lengthy thread about how to > use messaging. At first I thought is more of a middle tier framework > that would not be used by the UI. Oren said that messaging is a > perfect candidate for UI in that it pushes work to the background. At > least this is how I understood it. > > However, spiking a WinForm+Message application never really clicked > for me. A consumer is transient and managed by the service bus. the > consumers are processed on background threads. A Form/UserControl > wouldn't implement ConsumerOf<T> directly because updates must happen > on the main thread. I don't see the Presenter implementing this either > as the presenter would normally reference a Form/UserControl > (abstracted through a IView). > > Jeremy's example uses the ThreadPool.QueueUserWorkItem to push work to > background threads. I assume his example is still using a request/ > response model even though the work is delegated across threads. > > Assuming the application is complex enough to warrant a messaging > architecture: > 1. Would a WinForms use both a messaging framework and something > similar to Jeremy's example of the AsynchronousExecutor (see link > above), or would the system use one of the two options? > 2. If the choice is exclusive and I choose messaging. how do I handle > consuming a message that would ultimately update the UI? > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
