LabVIEW
VIs Called From TestStand Generate Events Before Running
I found a new and exciting way to have to force-quit LabVIEW.
This is technically a TestStand + LabVIEW thing, so I wasn't sure which board to hit up. This weird behavior seemed more LabVIEW-related to me, but let me know if I belong somewhere else!
Warning: this will lock up LabVIEW. Save anything important if you want to replicate this behavior.
Attached is a TestStand sequence that calls a single VI. Inside that VI is a combobox with a Value Change event and basically nothing else. I'm pretty sure this behavior happens for any control, but I originally ran into it while using a combobox.
Add a breakpoint in the TestStand sequence and step into the VI. When the VI opens, it's in some kind of suspended state until you click the run arrow. In this suspended state the front panel can still be changed. If you click the combobox and select any item, an event is generated even though the VI isn't really 'running'.
Because this event is stuck in the queue (and since the VI isn't running and can never respond), the Front Panel is permanently locked due to the 'Lock Panel' event option that is on by default.
The worst part, that I think elevates this to a bug, is you cannot run the VI now. The 'Run', 'Return to Caller' and other buttons are also locked along with the front panel. The only option at this point is to hard-abort, and depending on what windows you have open, possibly task-kill LabVIEW.
The work-around is easy enough (disable the 'Lock Panel' option), but this behavior sure makes it hard to debug using the step-into function.
I'm not sure what my goal is with this post (besides blowing off steam after spending half of today tracking this down). Does this reach the category of 'bug'? Anything I'm missing here?
