views:

149

answers:

3

We have an application with multiple subsystems running in different threads (ie one thread monitors the GPS, another monitors a RFID reader etc). The threads are started and monitored by a service registry which is seperate from the win forms part.

The initial release of the App just had a single form which would run on an update timer and just check the values of static variables on each of the subsystems every second or so.

I'm trying to clean this up, as we're adding in extra forms and there's virtually no thread safety with the current approach. I want each subsystem to throw a new event when its underlying state has changed so each form can subscribe only to the events it cares about and we can move to a more responsive UI...I don't like the update timer approach.

I'm running into problems here as events are triggered in the subsystems thread so I get System.InvalidOperationException exceptions complaining about cross thread calls when I try and update the UI with any state that is passed through with the event.

So at the moment, after reading through the msdn documentation, my options are to use control.invoke for each field I wish to update which is pretty annoying on complex forms with lots of fields, use background workers to run the subsystems in the forms themselves or have the forms still run on a timer and query the subsystems themselves, which I'm trying to avoid. I want the forms to be as separate from the underlying system as possible...they should only know which events they care about and update the relevant fields.

My question is, what am I missing here?? is there a better way I can architect this system so that the subsystems can run in their own threads but still send notifications off in a non coupled way?

any help would be greatly appreciated

cheers

nimai

+1  A: 

Rather than invoke across for each field you want to update, use a MethodInvoker delegate with BeginInvoke and call a method that does all your updates at once. For example ...

BeginInvoke( new MethodInvoker( MyUIUpdaterMethodHere ) );
JP Alioto
A: 

You can take a look at Event Aggregator pattern which basically allows a loosely coupled pub/sub type event-based architecture. Prism, a framework from Microsoft Patterns and Practices team for building composite applications with WPF and Silverlight has event aggregation that allows different UI components to communicate with each other in a loosely coupled way similar to your design goal. You can take a look at it and try to use just the event aggregation part of it. If not, you have access to the source code so that you can craft something that fits your requirements.

Mehmet Aras
A: 

You could use Windows Forms Synchronization Context to pass in a SendOrPostCallBackDelegate(or a lambda) which in turn can update multiple controls in a thread safe manner.

It sounds like these subsystems are running as a windows service. How is your winform app communicating to these sub systems.

Abhijeet Patel