Option for global key navigation that remains active even for controls in "other" tabs.

[altenbach]

Currently, key navigation only works for controls that can be seen. For example if a key is assigned to a control that is located on a tab page that is currently not visible, pressing the assigned key does not do anything.

There should be an option to override this restriction such that pressing the key will toggle the assigned button, even if it is hidden on another tab page.

As an example, I typically implement a way to interrupt the current DAQ operation or fitting process. Of course there is a "cancel" button on one of the tabs that does that too, but I typically also assign the "Esc" key to safely interrupt whatever the program is doing and revert to the idle state.

Unfortunately, if I assign "Esc" to my [Cancel] button, the key shortcut does not work if I am currently on a different tab.

As a workaround I typically place a small global sensor button outside the tab that carries the key assignment and is always visible. There are a couple of problems with this. I need extra code to handle both buttons. I need to waste FP space outside the tabs, which is often not available.

(Ideally, pressing the key should activate the assigned button silently, without switching to the tab where the button resides.)

All it probably needs is another option on the key assignment page, (see picture item underlined in red).

[X.]

I noticed that if you change the transparency of a VI up to 100%, you can't use it either... Go figure!

(I am actually half-jocking... I have a warning window that fades before it gets minimized if the user does not react to it, and while I was debugging it, I noticed this "feature", which somehow is relatively consistent. Or otherwise, I can't start imagining the pranks that could be designed based on "active" transparent VIs!).

[AristosQueue (NI)]

> Also note that if a button is not visible (property), the key navigations no longer work either.

> However, if I completely hide the button under a decoration, the key navigation continues to work. Go figure!

This is intentional. You saying "remove this from the panel" means "this isn't available for the user to click on and so shortcuts shouldn't work either". You covering a button up by a cosmetic is a programmer error or something like that. Or hacking around the system to create an invisible user shortcut.