FlexAPI Event Programming / GUI

Mark Erbaugh

I'm working my way into a WinForms based GUI program using the FlexAPI. At this point, I don't really know what I want to do with it, I just want to learn how to use C#, WinForms and the FlexAPI. From what I have figured out, updating a GUI must be done from the same thread that created the GUI. The FlexAPI generates events when some state of the radio has changed, but these events are generated on a different thread, thus to update the GUI, the event handler has to use Invoke (or BeginInvoke) to transfer the update to the GUI thread.

As a lot of my programming will be displaying information from the radio, a lot of my event handling for FlexAPI events turns out to be a simple call to Invoke to get the event onto the GUI thread. Maybe this is normal for event driven GUI programming, but it seems like I'm just trying to defeat the purpose of multiple threads. Am I on the right path, or am I missing something?

I understand that the difference between Invoke and BeginInvoke is that Invoke runs asynchronously, where as Invoke runs synchronously. Is there a preference for FlexAPI programs?

A lot of the events coming from the radio appear to be the same event, PropertyChanged. The program has to interrogate the event name to figure out what has changed. Would it make more sense to simply Invoke (or BeginInvoke) a GUI thread handler with the event as a parameter and have the GUI thread handler figure out what has updated and what to do with it? Or would it be better to interrogate the event in the event handler and invoke separate GUI based handlers.

Is the only way to interrogate a PropertyChanged event to do some sort of string matching? Initially, I see a huge switch statement with a case for every desired property change string, but I'm guessing a more efficient way would be some sort of dictionary based lookup to get the actual handler.

Or, thinking more about this, does it make sense to use a Queue to transfer PropertyChanged events from the event thread to the GUI thread?

As you can tell, I'm new to this, but I'm looking for any and all assistance.

73,
Mark - N8ME

Mark_WS7M

Hi Mark,

The preference is to keep your program responsive so choose between the standard and async based on if things start to feel slow.

Another key point is that you can do all the string matching and computations in the event handler outside of the invoke then only do the invoke around the actual field update.

Two ways you can approach the flood of data:

1) Compare the value to your stored value.  If the same just return and don't do any processing

2) Just store everything the radio sends in a dictionary.  Lookup Dictionary<> in C#.  You can create a Dictionary<string, string> and just add or update that dictionary as everything come in.  Then you can pass that around and pull values from it as you need them.

The dictionary probably should also be a ConcurrentDictionary.  This will allow the event handlers on different threads to update it while you are using it on other threads or in the GUI updates.

If you implement the dictionary you still will need to know when a value of interest changes so there still needs to be some kind of string match on the property name and decision made.

Mark Erbaugh

Thanks to the replies here, I'm progressing (hopefully).

I think this is more of a generic C# question, but I've been unable to find an answer via Google.

The code pattern I have seen to add a PropertyChange Event Handler is like:

Radio.PropertyChange += new PropertyChangedEventHandler(RadioPropertyChange);

but in my (simplified) testing

btn.Click += RadioPropertyChange;

seems to work. What's the difference and why the "new"?


73,
Mark  - N8ME

Mark_W3II

They are not different other than syntax. The first declaration was the old way of writing the code. Using just the name is the new preferred syntax.