Question

We have an application that is essentially implementing its own messaging queue. When a user interacts with the application it will generate an action, being a custom action and not the .NET class, that will be handled by our ActionDispatcher.

In the ActionDispatcher class I have a Stack of CustomAction objects. I’d like to run the ActionDispatcher in its own thread, but then you have all the issues with communicating with the main UI thread using Invoke and BeginInvoke.

There are several different methods that the ActionDispatcher may call, each one would require a delegate on the UI side to be used to communicate with the other thread I believe. Is there a simplier way?

The reason for wanting a seperate thread is that the ActionDispatcher processes messages that originate from a server as well as the UI. This is a client application, and many actions are generated by the server. The idea is that I have we have our own queue that both the UI and server add messages to.

Answer 1

It really depends on the architecture of your application, but the quick and short answer is: No. If you’re not on the UI thread, then you have to use the Dispather’s Invoke or BeginInvoke method to get access or execute code back on the UI thread.

As a side note, this is a little different than in WinForms, it almost sounds like you’re coming from a WinForms perspective, so you might want to look up the WPF Dispatcher.

On the other hand, I would suggest that you look into something like Prism’s IEventAggregator. I’m sure there are other similar implementations, but Prism has one nice feature, you can tell it you want to subscribe to an event and have it come in on the UI thread and prism does the rest of the work for you.

Personally, I think using an EventAggregator pattern is better, I’m not sure it’s necessarily simpler though.