Get rid of automatic key navigation assignment

[altenbach]

The "system OK" button has a predefined key navigation assignment for "Return (set focus on toggle)".

I argue that this automatic assignment is not a good idea and can lead to problems. Key navigation should never be automatic, but should be willfully assigned by the programmer when designing the front panel. A small extra step, which makes things predictable!

Lets see what happens if we place three OK buttons on the front panel. Can anyone guess which one will have the "Enter" key navigation assigned? (don't cheat!) As it turns out, it's the one we placed last! (Who would have guessed! :o). This also means that if we have a carefully constructed front panel with the enter key already assigned to a dedicated control, and we later add a "system OK" button to the panel, the existing assignment will get lost and transferred to the new OK button without warning. Greedy, greedy button!!!

This existing behavior has caused me problems numerous times in the past and I cannot remember a scenario where I wanted that automatic key assignment.

Suggestions: no control should have a predefined key navigation assignment. Ever! 

[Jarrod_S.]

Personally love this idea. You can tell which system button has the Enter key focus sometimes, because it might have a blue-ish highlight. But this is generally ugly and definitely not helpful.

[AristosQueue (NI)]

I'd argue that it is inherent in the functionality of an OK button to accept the Enter key as a shortcut, just as it is inherent in a Cancel button to accept Escape or a Help button to accept {your platform's help key here}. I'd be much more up for leaving the OK button just as it is and adding another button to the palettes that is named something like Action, a button which you clearly need to rename and which has no shortcuts tied to it unless you tie them. I *might* go so far as to make the OK, Cancel and Help buttons in the palettes be strict typedefs so that you cannot change the button text or the shortcut assignment for those buttons, thus encouraging LV UIs to follow the UI guidelines used by the majority of the world's apps, which says that Enter means OK and Escape means Cancel.

[altenbach]

If these buttons have default key assignments, then we would also need to define what should happen if two such buttons are placed on the diagram, because the current behavior is pure voodoo. Besides, there is a very pretty template available for simple dialogs, where default key navigation is desired. I don't mind of the dialog templates have these key assignments.

[kidding:] Maybe we need clippy that notices if you place an OK and cancel button in successions and that will pop up with "I see you are trying to create a dialog. Do you want to open a template instead?" [/kidding]. 😮

Another possibility would be to tone down the enter assignment a little bit. It should not trigger if a text (limit to single line) or numeric entry is completed with enter, only in most other cases.

The argument against extra buttons or type definitions is palette clutter, especially since the casual user would not know the difference. These key assignments are not immediately obvious. I think it is less damaging if a key assignment is missing compared to it's unknown presence. The user will realize in milliseconds that he needs to use the mouse after all. The skilled programmer will have no problems adding key bindings for a polished UI that follows all UI guidelines. If he starts with one of the templates, it's already done. 😄

The plain OK button never had an assignment and I could not find an idea here to give it one. I think the demand for it is not there.

[AristosQueue (NI)]

Alternative: If multiple buttons bound to the same key were dropped on the panel, break the VI until the user resolves. Not saying its a good idea, but noting it as a possible alternative.

[Neil.Pate]

If only I could kudo this up multiple times.

Buttons should never have default key navigation.

AQ, there are only two system buttons in the System pallette, so if you you want to drop a normal "action" button onto the FP the ok one is the obvious choice. I really don't think we need a separate button for an action button as this is to me 99% of the use case, ok is the special case in dialogues only.

This automatic assignment (especially the enter key) causes many subtle bugs...

[LabBEAN]

Related to a change in the default behavior of Key Navigation:  How about autochecking "Skip this control when tabbing" as well?  I suspect I just made some folks nervous by suggesting that...  So, can we at least turn "Skip this control when tabbing" ON for Error Clusters... Why would anyone want to tab to an Error Cluster control?

If you dislike manually controlling your tab order (that is, going to your Error Cluster and any off screen controls to turn "Skip this control when tabbing" ON) and get frustrated by not being able to tab into clusters (with hidden borders), see here.

[EdDickens]

I would like to throw my support behind getting rid of this bug/behavior as well. It has caused me numerous hours of needless debugging.

Most recently (just went through it) my application suddenly started acting very strange. My queued state machine was not running though the the proper states as it was before. I finally realize that in my last bit of modifications, I had dropped a system button down to allow the operators to manually run a test. The normal way to start the test is to scan in a bar code that contains the serial number of the UUT. The scanner adds a carriage return to the string. So every time a bar code was scanned, the application was trying to start both an automated test run and a manual test run. Even though the button was on a different tab and not even visible while the bar code is being scanned.

[sarcasm]

Of course the issue in this case was me forgetting about the hidden and automatic key assignment of the system buttons and turning it off right away.

[/sarcasm]

But I agree that a new button being dropped on a GUI should never transparently assign itself anything. Christian's point of a new button being dropped and stealing focus away from a button that you had previously manually set is valid. This should never happen, especially without any kind of notification. Depending on what that button does, this could have disastrous results.

I'd be OK with breaking the VI until you manually fix the assignment when there's multiple buttons. But would the VI also break if you drop a system button and no other buttons have the focus assigned? This is what last happened to me. Using the bar code scanner we can't have any buttons have focus or they get triggered every time the scanner is used. 

[altenbach]

Just another random story where this "feature" has caused endless (1 year!) problems. This really needs to change!

[AristosQueue (NI)]

Someone forgot to flip this idea over to In Beta. See you next week at NIWeek...