10-17-2013 02:41 AM
Hi, while strugling to get Labview to start with focus on an input field in Labview I also noticed that it completely ignores focus on output fields. Furthermore, reading on the subject I see a general attitude by people here that 'of course' you should only set (key)focus on input fields (???).
The current vi I'm using is a classic Labview vi without event handling, except those made by comparing previous and current value.
With quite some (I would say: largely unnecassary) effort I manage to start with focus on a certain input field.
I have a big nice "Calculate" button, which gets trapped and executed by pressing ENTER (using classic Labview "Key Navigation"). I want to progress the focus to an output field with its contents selected so users can immediately copy-and-paste the result.
After that I want to progress to the next output field when the user presses TAB, with more in- and output fields coming, also reachable through TAB.
Is this at all possible in Labview? Am I forced to convert the vi into an Event driven version?
10-17-2013 02:55 AM
10-17-2013 03:07 AM
Hi Ettepet,
event will surely help you to react on kay press events!
Thanks, I already figured it would help. Is it possible to overcome the "focus to input fields"-only obstacle, as your example does not do anything to countermand that.
10-17-2013 03:30 AM
10-17-2013 03:37 AM
not that I can think of.
Focus is given to input fields only AFAIK.
This is really weird as you can do it by clicking on the field in execution mode. "Power to the user!" I would say... (and yes, us software engineers are also to be considered users - special users)
10-17-2013 03:41 AM - edited 10-17-2013 03:41 AM
Hi Ettepet,
you can simulate selection in a text field as I tried to show in the attach VI above by changing colors of the text...
Why do you need to simulate focus when you can copy the text to the clipboard automatically as shown in the VI?
10-17-2013 03:50 AM - edited 10-17-2013 03:50 AM
you can simulate selection in a text field as I tried to show in the attach VI above by changing colors of the text...
Why do you need to simulate focus when you can copy the text to the clipboard automatically as shown in the VI?
I want a proper user interface, working as the user expects it. It is NOT normal to have focus on input fields only, as I've seen it working properly in many programming environments in the past.
10-17-2013 03:58 AM
Hi Ettepet,
two more things:
- I never have seen a UI with an indicator with key focus.
- you can get your key focus behaviour by using a control instead of your indicator and settings it's value with a local variable or property node... I'm sure other programs fake that too...
10-17-2013 04:42 AM - edited 10-17-2013 04:43 AM
two more things:
- I never have seen a UI with an indicator with key focus.
- you can get your key focus behaviour by using a control instead of your indicator and settings it's value with a local variable or property node... I'm sure other programs fake that too...
You can stress the "indicator"-ness however you want but it still makes no sense. 95% of code probably won't have need for it, but not even allowing software engineers to "choose" to use it is plain ugly. It makes for an unnecessarily rigid interface, where in many / most other programming environments the environment itself allows it if so desired.
The trick to make it a Disabled (but not Greyed-out) control doesn not work, meaning I can only make it an Enabled Control. I envision trying to explain to users and the test-department and colleagues that they can edit the output field "because my programming environment doesn't allow me otherwise...".
10-17-2013 04:45 AM