Option to discard any user actions outside an event case if the front panel is locked

[AndyRR]

If you make an event case that opens a SubVI dialog window, you can lock the front panel until the dialog is closed. However Labview remembers all user actions and will execute them as soon as the event case is completed.

Example below:

If the user opens the SubVI dialog and then clicks on of the buttons: Button1,2,3, Labview will remember the clicks and execute the clicks when the SubVI dialog is closed (event case completed).

Therefore I would like to have an option to discard any user actions outside an event case if the front panel is locked. My suggestion below:

Example VI's as attachment

[TroyK]

Perhaps I misunderstand the suggestion, but isn't a similar thing accomplished by making the dialog 'modal'?

Once a modal child window is opened, the parent window no longer accepts user input, all you get if you try is a system default beep.

[tst]

> ...isn't a similar thing accomplished by making the dialog 'modal'?

Only if you have a dialog. I run into something similar sometimes where users double-click a button which dismisses a dialog. They do it quickly enough so that LV registers the second click, which means that the next time they open the dialog LV immediately processes the click from last time and usually dismisses the dialog as soon as it is opened. An option like this would help with that scenario.

[AndyRR]

Sorry, I'm still quite new with LabVIEW. Troy K, yes, the preferred functionality is achieved by making the dialog modal, thanks. I should have studied VI Window Appearance properties more closely before posting this idea.

Actually I would still like to have an option to discard any user actions until an event completes, but for a different reason. This would be useful if the program is executing a time consuming task and you want to ignore all user inputs during the execution. Of course it is possible to work around this problem e.g. by displaying a modal window that says loading and then closing it with a notifier when the task is completed. However it would be nice to have an easy option to discard (not just defer) user inputs during an event execution. I'm not aware of an easy way to do this.

[dthor]

I would like this as well. For now, my work around is to create user events immediatly before the event structure is executed and discard them immediatly after. It works pretty well, but does make the code kind of big.

[AristosQueue (NI)]

I went off to talk to developers more knowledgable about this than I, and in the meantime it appears your immediate questions have been resolved. I like it when customers are able to help each other. Saves me work. 🙂

Anyway, what I learned:

Yes, you should make the subdialog "modal" to avoid this effect now.

Yes, something like this would be useful for long-running event operations where you're not throwing a dialog, although they suspect perhaps a mechanism for flushing the event queue inside the event structure would be better than a statically configured option. In the meantime, you can disable the mouse cursor at the start of your event and re-enable it at the end of your event. Use the "Set Busy.vi" and the "Unset Busy.vi" functions, as shown below. This locks out both mouse events AND keyboard shortcuts to controls and the menu bar.

[dthor]

Regarding Set Busy and Unset Busy: That's good to know. However, that disables *all* interactions with the FP, sometimes we only want to stop things from queueing 

But I agree, the best option would be a programmable way to flush the event queue.

[AndyRR]

Thanks Aristos Queue, Set Busy and Unset Busy is good to know.

One more thought about modal and floating dialogs, floating has the advantage that you can press the abort button from the main VI. I have also noticed that if I have a modal SubVI dialog and then open an additional SubVI dialog from that, it must also be modal. Otherwise it disappears somewhere behind the first modal dialog and the program must be closed with force from Windows taskbar or task manager. I just have to be more careful and remember this when developing programs with modal SubVI dialogs.

[tannerite]

It sounds like this is would be disabling the queue of the event structure until the front panel unlocks, which would be a good suggestion. There is a workaround for this:

https://decibel.ni.com/content/docs/DOC-7194