Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR, Power Genius, Tuner Genius and Antenna Genius Software?
SmartSDR v3.8.20 and the SmartSDR v3.8.20 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
SmartSDR v3.8.20 and the SmartSDR v3.8.20 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
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.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
FlexAPI Event Programming / GUI
Mark Erbaugh
Member ✭✭
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
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
0
Answers
-
0
-
0
-
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.0
Leave a Comment
Categories
- All Categories
- 260 Community Topics
- 2.1K New Ideas
- 538 The Flea Market
- 7.6K Software
- 6K SmartSDR for Windows
- 139 SmartSDR for Maestro and M models
- 368 SmartSDR for Mac
- 242 SmartSDR for iOS
- 226 SmartSDR CAT
- 175 DAX
- 345 SmartSDR API
- 8.8K Radios and Accessories
- 6.9K FLEX-6000 Signature Series
- 44 FLEX-8000 Signature Series
- 859 Maestro
- 45 FlexControl
- 849 FLEX Series (Legacy) Radios
- 807 Genius Products
- 424 Power Genius XL Amplifier
- 280 Tuner Genius XL
- 87 Antenna Genius
- 227 Shack Infrastructure
- 153 Networking
- 409 Remote Operation (SmartLink)
- 130 Contesting
- 640 Peripherals & Station Integration
- 116 Amateur Radio Interests
- 878 Third-Party Software