Make Stylet multiple UI threads safe?

[mwdpb]

Background: in Excel VSTO application, the TextBox in a WPF window will not get keyboard focus unless the window is modal (if you type anything, it will go to the Excel cell that the cursor was in before launching the WPF window, see https://stackoverflow.com/questions/5869359/wpf-modeless-dialog-from-ms-excel-add-in.) You can get away with it by using WindowManager.ShowDialog(new VM()) which makes it modal. However, it isn't ideal as that means you can't go back to Excel without closing the current window. I encountered this exact problem when I was using Caliburn.Micro a few years ago and there is an elegant solution by creating a new UI thread and everything works fine. The code snippet is here:

Granted I encountered the exact problem with Stylet, and tried the same approach and it errors out in CommandAction.UpdateCanExecute, see screen capture below:

If I go ahead and comment out that if statement, it works fine except I don't get command guards anymore. It seems Stylet assume single UI thread and that if statement trying to go back to the main UI but since this window was created in a separate UI thread, it couldn't access its objects. How hard to make Stylet multiple UI thread safe? Any thoughts?

FWIW, here is an article talking about multiple UI thread application. We certainly don't need multiple UI threads everyday, but there are situations that do justify creating separate UI thread.
https://eprystupa.wordpress.com/2008/07/28/running-wpf-application-with-multiple-ui-threads/

[canton7]

If you set Execute.Dispatcher = null in your bootstrapper's Configure method, does that fix the issue? That will make Execute.OnXXX methods dispatch synchronously, rather than trying to dispatch to the Application's UI thread. Of course, you're then responsible for making sure you raise events (such as INPC or INCC) on the right thread!

Ultimately though, why not run the entire application on a new thread, rather than juggling two UI threads?

[mwdpb]

I think you can either just delete the whole if statement in the setter or remove null coalescing in the getter, right?

[canton7]

I'm not going to do either of those: if I remove the coalesce then the consumer needs to check for null, and along with just moving the problem to the consumer I might break someone. If I remove the null check I create a property which doesn't behave like a property, which is bad.

I'm going to make SynchronousDispatcher singleton and expose it.

[mwdpb]

I like the singleton idea!

[canton7]

See 3959702

[mwdpb]

I see it, I'll check it out. Thank you!