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
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 …