Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

FlexAPI Event Programming / GUI

Mark Erbaugh
Mark Erbaugh Member ✭✭
edited February 2020 in SmartSDR API
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

Answers

  • Mark_WS7M
    Mark_WS7M Member ✭✭✭
    edited August 2019
  • Mark Erbaugh
    Mark Erbaugh Member ✭✭
    edited February 2020
  • Mark_W3II
    Mark_W3II Member ✭✭✭
    edited August 2019
    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.

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.