Home Support NI Product Manuals LabVIEW Communications System Design Suite 5.0 Manual

Table Of Contents

Recommendations for Event-Driven Programming

Download Manual | Offline Viewer Required
Version:
Last Modified: February 27, 2020

Because handling events in G Dataflow is different from handling events in other programming languages, follow NI's recommendations for event-driven programming.

General Recommendations

Recommendation Details
Place the Event Structure in a While Loop that terminates when events can no longer occur. Using a While Loop ensures that the Event Structure can handle events whenever events occur. Without a While Loop, the Event Structure handles only the first event it receives. If the VI queues events after the Event Structure finishes executing, the Event Structure cannot handle those events.
To ensure that every queued event is handled, design the VI to finish running soon after the Event Structure stops executing.

The VI uses an event queue to store events and handle them in the order in which they occur.

Because the VI queues events for the entire time that it is running, the VI can queue events after dataflow causes an Event Structure to finish executing.

Use caution when placing an Event Structure within a Case Structure.

If a Case Structure prevents an Event Structure from executing to handle events, the Event Structure cannot handle events when they occur.

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.

Wire each Event Structure that handles dynamic events to a unique Register for Events node. Branching the wire from a Register for Events node allows multiple Event Structures to pull events from one queue, resulting in a race condition that may cause unpredictable behavior.
When you use multiple Event Structures in the same VI, observe the following guidelines:
  • Place each Event Structure in its own While Loop.
  • Wire your diagram code so that the Event Structures execute simultaneously.
  • Wire your diagram code so that the Event Structures stop handling events simultaneously.

You can use multiple Event Structures in the same VI, especially if you register for events dynamically.

For example, you can place two Event Structures within two separate While Loops that are subject to different stop conditions.

Use Unregister for Events and Destroy User Event to unregister and destroy user events. The VI unregisters all events and destroys existing user events automatically when the top-level VI finishes running. However, to conserve memory resources, unregister and destroy user events explicitly, especially in an application that runs for a long period of time.

Notify and Filter Events

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.

Events and Loops

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.

Events and Latched Boolean Controls

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.

Recently Viewed Topics