DelegateCommand & WeakEventManager assume there is only 1 UI thread. Need multiple UI thread support to meet performance requirements for multi-monitor complex UI apps.
Comments: Correct - I have encountered this problem too. The code as it currently exists is flawed, because it depends on what thread the WeakEventHandlerManager is initialized on. I encountered a problem because I use a separate thread to display a splashscreen for my application, and the WeakEventHandlerManager was being initialized there since I am using a DelegateCommand for the UI portion. Later, when I use DelegateCommands in my main app, the events are never fired. It would seem that this could easily be fixed by not caching the SynchronizationContext in WeakEventManager. My suggestion would be to do something like this instead: private static void CallHandler(object sender, EventHandler eventHandler) { if (eventHandler != null) { SynchronizationContext syncContext = SynchronizationContext.Current; if (syncContext != null) { syncContext.Post((o) => eventHandler(sender, EventArgs.Empty), null); } else { eventHandler(sender, EventArgs.Empty); } } } What was the original intent of caching the SynchronizationContext? Why was something like the above not used instead?
Comments: Correct - I have encountered this problem too. The code as it currently exists is flawed, because it depends on what thread the WeakEventHandlerManager is initialized on. I encountered a problem because I use a separate thread to display a splashscreen for my application, and the WeakEventHandlerManager was being initialized there since I am using a DelegateCommand for the UI portion. Later, when I use DelegateCommands in my main app, the events are never fired. It would seem that this could easily be fixed by not caching the SynchronizationContext in WeakEventManager. My suggestion would be to do something like this instead: private static void CallHandler(object sender, EventHandler eventHandler) { if (eventHandler != null) { SynchronizationContext syncContext = SynchronizationContext.Current; if (syncContext != null) { syncContext.Post((o) => eventHandler(sender, EventArgs.Empty), null); } else { eventHandler(sender, EventArgs.Empty); } } } What was the original intent of caching the SynchronizationContext? Why was something like the above not used instead?