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).

[dthor]

Definitely agree. Right now I place all my "global" buttons outside of the tabs so that hotkeys work. It takes up quite a bit of real estate.

[X.]

It looks like a hack to me. I am no UI Guru, but having a shortcut for a hidden object does not sound "natural". I totally understand the function (and I have wished that a few times), but I would disagree with the hack. Fundamentally, if you want something that is active no matter what is displayed on the font panel, you are talking about a "menu shorcut" (a menu is visible no matter what tab of your panel is shown). You may not be using a menu, but maybe you should. It is a very common thing in nowadays software (well, I don't have a smartphone or an iPad, so I may be a bit dated on this, and my pun may fall flat).

I am not sure how you would be able to associate the Escape key to a menu item (if at all), but I suppose you could be content with another shortcut?

But obviously all this is philosophical, typed while sipping my morning cup of coffee...

[Darin.K]

I handle this with Key Down events myself. I see this more as syntactic sugar than a hack.

[X.]

"syntactic sugar". I will have to try this one in a conversation some day!

[Manzolli]

I'm thinking about this one. Sometimes may be useful. I agree with X. A new global option to turn this behavior on and off, may be the key element to make everybody happy.

[AristosQueue (NI)]

To take another variation on .X's comments: If you have control functionality that should always be on the panel, perhaps you should make that control always on the panel. You can make the control float over the tab control so it doesn't disappear when tabs change. Having a button that silently changes an unseen value would lead to a user interface where the user accidentally bumps their keyboard but sees no indication that there was any effect and so keeps working. I would frown on such a UI.

[altenbach]

However, key assignements are currently global and you cannot have the <escape> key asigned to two different controls, even if they are located on different tab pages and thus can never be visible at the same time. (This somehow seems incomplete, does it?!)

> Having a button that silently changes an unseen value would lead to a user interface where the user accidentally bumps their keyboard but sees no indication that there was any effect and so keeps working. I would frown on such a UI.

I think it is up to the programmer to ensure that something noticably happens if a hidden boolean is triggered. After all, the default should be the current behavior, so there is no problem. The <escape> button is a very common examples and is used everywhere, not just in LabVIEW. Typically it means the program should stop whatever it is doing right now and go back to the idle state ("Stop that!!!" in the international language of key navigation). I don't think we need to actively see the button go down and back up to understand what is happening.

The <escape> key is typically the only key I have assigned. In my fitting program I also have the <home> key assigned, because parameter and settings are distributed over several tabs due to the complexity of the problem and we should be able to start fitting ("<home>ing in a best fit" ;)) without first going to a specific tab. Same difference.

Implementing this idea would help me, and hopefully some others, a lot. 😄

[X.]

This is a good point, Christian. Should the scope of boolean shortcuts be that of a panel, a pane, a tab? I have no opinion.

But hopefully you get the points of others who are reluctant to have hidden booleans activated by one key stroke. It's nerve racking... and potentially I can see a programmer inadvertently becoming a victim of it.

Darin's workaround seems simple enough if the Event "Key Down" does not supersedes all shortcuts (I don't know and I did not check).

[rgvdh@rdf]

> I don't think we need to actively see the button go down and back up to understand what is happening.

That's already easy enough - just make the button invisible.  If it's always invisible, presumably the user has some other way of knowing what they're supposed to do to make something happen, and of knowing that it happened.

It's the idea of having a button you can hit with your mouse only when it's visible, but you can change the state of via the keyboard even when you can't see it, that strikes me as inconsistent, confusing, and such a bad idea that I'd rather LabVIEW didn't do anything to make it easier for people to do.

>Should the scope of boolean shortcuts be that of a panel, a pane, a tab? I have no opinion.

Can't you control that by where you put the (possibly invisible) boolean?

It's having the mouse control scope and the keyboard control scope be different that I object to.

>However, key assignments are currently global and you cannot have the <escape> key assigned

>to two different controls, even if they are located on different tab pages and thus can never be visible

>at the same time. (This somehow seems incomplete, does it?!)

It does, and I think it's the real problem.  Someone might well want to assign <esc> to do analogous things on different tabs.  But it should operate on the tab that's open, leaving hidden ones alone.

[rgvdh@rdf]

>However, key assignments are currently global and you cannot have the <escape> key assigned

>to two different controls, even if they are located on different tab pages and thus can never be visible

>at the same time. (This somehow seems incomplete, does it?!)

It does, and I think it's the real problem.  Someone might well want to assign <esc> to do analogous things on different tabs.  But it should operate on the tab that's open, leaving hidden ones alone.

[altenbach]

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!