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
-~----------~----~----~----~------~----~------~--~---

Reply via email to