I haven’t had the time – has it been almost 2 years since I wrote this?!

Have you had chances to write those “next installment” in the Smart Client series?
What about the software factory you mentioned?
I am very much interested!

Glad you liked it.
The software factory is beginning to take shape.

br,
karl

Yes, that seems reasonable, thank you for your answer.

–larsw

SyncContext is good for dispatching a call back to to someone who called you before – ie async request/response scenarios.

If the controller receives a notification from the server requiring to pop up a “toast” without any original call coming from the UI, it wouldn’t have access to the necessary sync context. In other words, a “response” without a request.

Another thing not handled is if two threads are trying to access two different objects (say customer and order), getting an infrastructure style global locking behavior between those threads.

Does that answer your question?

What does this solve that the System.Threading.SynchronizationContext (w/ friends) doesn’t solve?

–larsw

Thanks.

I checked out your post and what’s different here is that the ISynchronizeInvoke is being injected into the controller (as simple as injecting the main form). It doesn’t matter which object is the target of the delegate.

I wrote something similar, wihtout the sync domains, a couple of years ago: http://www.lowendahl.net/content.aspx?cshrpContent=csa31

One of the problems I’ve been struggling with is that it’s only the immediate level that will know if invoke is required with the InvokeRequired property, If we are using an intermediate class that are the target of the delagate instead of a control / component, the problem will still be the same.

This means that all components in a forms scenario needs to inherit from the baseclass and send events upward, or only one level of indirection can be allowed in theese scenarios.

Are theese challenges the same in your approach?