Modern software applications usually require some degree of user interaction. User actions such as mouse clicks or keyboard inputs are known as user events. When your OS detects that such an event has occurred, it notifies applications so they can react by executing any code written specifically for that event. With National Instruments LabVIEW, you can develop sophisticated event-driven applications with unique responses to user actions through the LabVIEW event structure, which provides a simple, effective way to combine dataflow and event-driven program execution.
How the Event Structure Works
Developing event-driven applications with the LabVIEW event structure is an intuitive process. The event structure contains code that executes only if the OS detects specific events at run time. Within the event structure are multiple subdiagrams, each corresponding to a specific event and containing information related to that event. For example, if the OS announces that a Mouse Down event has occurred on a button named Start and your event structure is configured to respond to that particular event, the Mouse Down subdiagram for the Start button includes data such as the mouse coordinates, a control reference to the Start button, and the system time at which the event occurred (see figure). You can use this event data to customize the behavior of your application. For example, to change the properties of the Start button once it is pressed, you can wire the built-in control reference to a property node and select the control properties to modify.
With the event structure, LabVIEW developers can define specific reactions to user actions on the front panel.
Event Structure Benefits
The event structure also provides an efficient method to achieve event-driven program execution. Prior to the event structure, the best method for UI monitoring in LabVIEW required actively polling the front panel for control value changes. However, polling has its limitations, such as increased execution overhead, missed control value changes, and the inability to determine the order in which multiple changes occurred. In contrast, the event structure responds to every registered event detected by the OS and executes those responses synchronously in the order the events occurred. To minimize resource usage, the event structure sleeps until notified of an event of interest, eliminating the overhead associated with polling. You can even configure the event structure to time out if it fails to receive an event of interest within your defined period, which helps prevent the application from hanging.
Advanced Event-Driven Programming Techniques
In LabVIEW 7.1, the event structure responds to statically registered events, which are registered at edit time, and dynamically registered events, which are registered as the program executes. By dynamically registering events, you gain control over the circumstances under which your program responds to those events. For example, using dynamic event registration, you can create programs that only respond to user events once the user explicitly requests this behavior. Dynamic event registration also has another advantage – with dynamic events, you can configure the event structure to detect events generated on any object to which it has a reference. As a result, a single subVI can perform all the event handling for your top-level VI, thereby modularizing and simplifying your block diagram.
You can even create your own user-defined events and generate them programmatically to communicate between separate parts of your application, reusing your event structure for non-UI purposes. In a program that already uses event-driven programming, this makes your code more organized and easier to comprehend.
Using the LabVIEW event structure, you can create responsive, sophisticated UIs without sacrificing program performance or readability. With the ability to dynamically register and programmatically generate events, you now have more control over the behavior of your application than ever before.
Michael Neal
LabVIEW Product Marketing Engineer
michael.neal@ni.com
This article first ran in the Q3 2005 issue of Instrumentation Newsletter.