Key focus behavior of controls

[Felmer]

Hello,

I came across a point with key focus behavior and interferences with key navigation. To understand the point I´m going to describe the actual behavior and the expected and documented behavior.

Expected behavior

Some controls like Boolean button, strings or numeric supports return/enter based key focus behavior. A Boolean button toggles the value, a string makes a new line (return) or enters the input (enter) and a numeric enters the input. Now we are also able to define key navigation which allows to toggle a Boolean button with the Return button of the keyboard. What would we expect in this place? I would expect that if key focus is NOT active the key navigation is activated and if key focus IS active the key focus behavior has priority. The Knowledge Base Article points to that expectation ("If any control uses the <RETURN> key navigation, pressing this key will only activate that control if no other control has key focus. The key focus behavior has priority over the key navigation.").

Actual behavior

The above expectation is true for Boolean buttons. This means if I have active key navigation with Return to a button and I set key focus to another button and press Return I toggle the button with key focus and not the button with the configured key navigation. This is expected and fine so far but does not work with numerics or strings. If I try it on such controls the key focus behavior is not activated if I press Return but only the key navigation behavior is activated. I find this behavior really weird because the knowledge base article states otherwise and also other software doesn´t behave like this (Try it for example with windows dialogs...).

To test it you only have to place some controls on a blank VI and change to run mode. I tested it with LabVIEW 2012 SP1f3.

Do I miss a point here or is this some kind of bug?

[mikeporter]

If I understand what you are saying, it is a bug -- and a very old one at that. Typically, the only kind of control where it causes problems is numerics because with strings you can set a property such that LV will see changes while typing, thus avoiding the problem. With numerics, though, you have the problem that if you have typed in a number and immediately press the return key, the value that is seen at the numeric's terminal is not the value you were typing. That value only gets passed to the terminal when numeric control loses key focus -- which as you point out doesn't happen with key navigation.

Fortunately, the fix is simple. In the event that handles the value change event for the button that is configured to be "pressed" with the key navigation, put a property node to force the button to have the key focus. This will cause the numeric to update its value correctly.

Mike...

[Felmer]

Thanks for your reply Mike. I see several problems with this workaround. Your suggested workaround only addresses some specific use cases and doesn´t work on all of them. So if I want to use the key focus behavior to input several numerics I wan´t that after entering data into a numeric and applying them with RETURN that I can enter the next numeric. With your workaround I may get the "Value Change"-Event for the numeric but also the button with active Key Navigation gets pressed. Furthermore the order of events is in the false order. The expected and documented behavior would lead to only the Numeric "Value Change"-Event. With the workaround I get the "Value Change"-Event of the Boolean followed by the Numeric.

So this workaround only works if leaving for example a dialog after inputting one value is OK. Futhermore I have to ensure that the terminals are read after the "Key Focus" property and no specific event handling is possible.

I think this restriction don´t work really often.

[mikeporter]

I think you misunderstand. The only time the problem occurs is when you press the return key to trigger the key navigation on the button.

Say you have several numerics, as you tab between them each updates as it should because tabbing causes a change in key focus. The problem is that the key navigation doesn't.

Mike...

[Yamaeda]

You can remove the Key navigation of the button and implement your own with Key pressed-event. Use the description, if the key has focus, do action X, else do nothing.

/Y

[Felmer]

@mikeporter

Why should this solve the problem? I want to finish the loop directly after pressing the Button with active Key navigation so the Key Focus = TRUE fires the event for the last numeric but i can´t process it because i already left the loop.

Furthermore "Update while typing" is not every time a solution because sometimes i want the total input and process it and processing partial inputs may have consequences.

@Yamaeda

Implementing the Key navigation to behave correctly involves some coding and is possiblly a performance hit. To implement the correct behaviour i have to check if no other control has key focus (or no control with key focus functionality when pressing RETURN) and this involves highly specific code or much VI server interaction. I think this is really the wrong road to go.

In the mean time i investigated further an discovered that activating the option "Set to focus on toggle" solves the issue.

But in the long run this problem should be addressed because without this option the priority of Key Focus over Key Navigation is not valid for all cases (for boolean controls it works like expected but for numerics not).

[mikeporter]

Ok, I see what the issue is here. You aren't interested in hearing answers - just complaining. I was considering creating a small demonstration to show the problem and the solution, but you aren't interested so I won't bother. You know it is generally considered polite to listen to what you are being told before dumping on it. Still I am the eternal optimist, so I will give this one more try:

The solution I gave does indeed only address one use case - but it just so happens it's the only use case you have to worry about. The problem (by definition) doesn't exist for controls you actuate by mouse because as soon as you let up the mouse button LV knows you are done changing the data value and registers the change. The only use case pertinent to this discussion is when the cursor is in a control you can type into (digital numerics or strings) AND you have key navigation set to press a button when you hit the return key.

In that situation, one solution is the setting you mentioned - that existed before, but it didn't work corrrectly due to an internal race condition, I'm glad to hear that NI fixed it. The other solution is the one I gave. In the event handler for the button that is pressed by the key navigation, set the key focus to the button using a property node before you read any of the numeric or string inputs to generate your final output action.

If you still don't like this answer, perhaps you should - never mind...

Mike...

[Felmer]

I´m sorry if my post offended you. This was not the intention.

Your suggestions have clearly a point to a solution. The problem I see here is that im forced to design and program in a specific way. I have to read all numeric or input data at the end of the event handling loop to output the correct data. I´m not able to handle each individual Value Change and react on the changes and maybe alter other values.

I want to avoid that because then I can´t use the full possibilities of the event structure and the intentions behind it. If i don´t implement your suggestions the end user of the software gets a bad user experience because the UI doesn´t behave equal when controling with the mouse or the keyboard.

Futhermore your suggestion doesn´t fix the issue that an RETURN in an key focused numeric doesn´t behave the same way in all configurations of the key navigation. I think this is a main issue. If you toggle booleans with the keyboard (SPACE or RETURN) it doesn´t matter if key navigation is configured. The Key Focus has priority over the key navigation. With numerics this doesn´t work so I have also a problem at this point.

Your suggestion fixes the Value Change Event problem but I still leave the loop unexpected.

I attached an simple example showing this issue. If you deactivate the Key Navigation of the OK Button you can see the different behaivor when using RETURN. For comparision i also added boolean buttons to show the different behavior.

I thank you for your answers in this thread and apologize for my offending post.

[Yamaeda]

What i do is set the OK button to Focus on Return, then you'll tab out of the text field and select the button. Then, as expected, another return will activate the button.

/Y

[Felmer]

Your right that solves the issue regarding "data integrity". With this option I get the latest value change event before the Boolean is triggered through the key navigation. See my post above which also mentions this.

But the expected priorization of the key focus behavior over the key navigation doesn´t apply to this. I´m not able to enter a value in a numeric and apply it with RETURN without triggering the key navigation button.

I´m going to use the "Set Key Focus on Toggle" and hope that nobody complains about the inconsistence. I think that numerics are not following the priorization is a bug. I thought about many possible solution approaches but there are not many approaches which addresses the "data integrity" and the priorization issue. And I further think its not feasible to implement the key navigation from scratch in the user code.

Thank you for your contribution and suggestions Yameada and Mike!