Hanging on an Event Structure

A LabVIEW user interface I was working with hung recently. I suspected the front panel was locked because I had done something stupid, but I was surprised to find out what it was. I had put an Event Structure in a case structure that wasn’t executing and this had caused the hang.

climber hanging

You may ask, “Shawn, what were you thinking putting an event structure in a case structure anyway?”. It seems like a bad idea, but the reason I did it is I had a user interface VI that was shown while an automated test runs. Normally, the user can’t control the test and the event structure doesn’t execute. However, if the test is run in development with a debug option, then the event structure runs and allows the developer to run different options and debug the automated test. I liked this ability to debug the automated test with an event structure, and that’s when I ran into the problem.

Let’s discuss why LabVIEW was locking up. The “Lock Front Panel” option is a feature for any event case that handles a Control on the front panel:

Edit Events Menu

Edit Events Dialog

Checking this box will cause the mouse to not function for any LabVIEW Window until that event case is finished executing. This box is checked by default, and the LabVIEW help for this feature is quite good at explaining the behavior. The front panel remains locked until the event case finishes, which is normally an unnoticeably small amount of time.

The problem that occurs is that the panel becomes locked when the control receives the event even if the event structure doesn’t actually execute. The VI Snipped below shows an example of this behavior:

Hang on Event

The Event case is in the True case of the above case structure. When the VI runs, clicking on the listbox will work once, and after that the panel will be locked and neither the listbox, the close button, nor the stop button may be clicked.

The solution is to not put an event structure in a place where it can’t run! This is the best solution, but since it may not always be possible due to design constraints, here are some others:

  1. Uncheck the Lock panel checkbox. This has the downside that if the event structure can’t execute fast enough, then some user actions may be queued up before the event that is currently executing can finish. It’s also a nuisance to remember to uncheck the normally checked box in the situations you need it unchecked.
  2. You may dynamically register for the event in the case where the event structure does execute. This is somewhat painful, but if you really need an event structure that only sometimes runs, it’s a good method that doesn’t have bad sign effects.

In summary, be careful with out there, especially when doing stupid things with Event Structures.

Shawn Walpole

Senior Systems Engineer

Shawn Walpole started programming with Microsoft Basic on the Apple Macintosh 128k computer in the 1980s and has loved it ever since. He graduated with a Mechanical Engineering BS degree and a Computer Science minor from the University of Utah in 2000. He worked on the LabVIEW R&D team at National Instruments for four years developing LabVIEW before moving to Moore Good Ideas. Shawn was impressed by Endigit's vision and joined the Endigit team in 2014.

Shawn gets job satisfaction out of meeting customer needs. He likes LabVIEW because well-written code is easy to read and because of the power of a development environment that was written for programmers working with real hardware.

Shawn has industry experience programming LabVIEW and C/C++. He has worked with Real Time, FPGA, DAQmx, Motion, TestStand, and Veristand.

Add new comment