Because handling events in G Dataflow is different from handling events in other programming languages, follow NI's recommendations for event-driven programming.
Recommendation | Details |
---|---|
If you want to modify how the application processes a user interaction, use a filter event. | When you configure an event case to handle a filter event, you can use the Event Filter Node to discard the event or interact with data associated with a user action on the panel before the Event Structure executes a subdiagram of code. |
Avoid configuring one Event Structure case to handle multiple notify events of different data types. | A single case in an Event Structure can handle multiple notify events. However, if the events are not the same type, only the event data fields common to all events that the case handles appear on the Event Data Node. |
You cannot configure one event case to handle multiple filter events with different data. | A single case in an Event Structure cannot handle multiple filter events unless the events have identical data. Because you can modify the data, the Event Structure cannot consolidate the data like it can for notify events. |
Avoid using dialog box nodes in an event case with the Mouse Down? filter event. | Event cases that prompt users with a dialog box can cause unexpected behavior in the VI. Instead, place the dialog box inside the Mouse Up event case or outside the Event Structure. |
Do not use the Panel Close notify event for shutdown code. Instead, use the Panel Close? filter event or open a reference to the VI before a user can close the panel. | Including shutdown code in your VI allows you to stop the VI in a controlled manner and protect data. If you use the Panel Close notify event to execute shutdown code, the VI can abort before the shutdown code executes. |
Recommendation | Details |
---|---|
Avoid placing code that takes a long time to execute within the Event Structure because the UI will not be able to respond to additional user input until the operation finishes. |
If no Event Structure executes promptly to handle an event and panel event pausing is enabled, the user interface of the VI may become unresponsive. If you have enabled panel event pausing, the user interface of the VI can become unresponsive. For example, if an event case launches an application that requires text entry from the user, the user might begin typing before the application appears on the panel. If panel event pausing is enabled, once the application launches and appears on the panel, it processes the key presses in the order in which they occurred. If panel event pausing is disabled, the key presses might be processed elsewhere on the panel. To enable or disable panel event pausing, use the Pause panel event processing until complete checkbox on the Item tab of the Event Structure. |
Avoid placing two Event Structures in one loop. |
If you place two Event Structures in a single loop, the loop cannot iterate until both Event Structures handle an event. For example, if you place two Event Structures in a single While Loop and configure the first Event Structure to handle a Mouse Down event and configure the second Event Structure to handle a Key Down event, if the user clicks the mouse button twice with no intervening Key Down event, the user interface will not respond to the second until the user presses a key. |
Recommendation | Details |
---|---|
When using events with latched Boolean controls, place the control inside the event case so that the mechanical action of a latched Boolean control behaves correctly. |
When you trigger an event on a Boolean control with a latched mechanical action, the Boolean control does not reset to its default value until the diagram reads the Boolean control. For example, if you wire a latched stop Boolean control to the condition terminal of a While Loop, create an event case that handles the latched stop Boolean control in the Event Structure. |
When you wire a latched Boolean control, place the Boolean control in its Value Change event case. | |
Use a Case Structure within the event case to handle undo operations for a latched Boolean control. |
When you perform an undo operation on a Boolean control with a latching mechanical action, the Event Structure handles the undo operation as a Value Change event, which might return unexpected results. Use the True case of the Case Structure to specify how you want to handle the Boolean control and the False case to specify how you want to handle the undo operation. |