LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

finish prompt user vi with "OK" via enter key press

I want to integrate a pop up window that asks the user to enter a value.

 

I used the express vi for that.

I added a default value, similar to this: http://forums.ni.com/t5/LabVIEW/quot-Prompt-User-quot-dialog-default-input-text-field/td-p/2173194

 

I do not want to only click on the ok button to close the dialog but also want to be able to do this by hitting the enter key.

 

I followed this manual:

http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/setting_keyboard_shortcut/

 

However, I am not able to achieve the desired effect:

If I add <Enter> to the focus section, I have to press enter twice (once to get the focus on the ok button and the second button to change the value).

If I add <Enter> to the toggle section, I am able to close the dialog box by pressing the key, however, the vi outputs the default value and not what the user entered in the input control.

 

I cannot add <Enter> to both focus and toggle.

 

How do I let the user enter a value and both close the dialog and accept the entered value with a single stroke of the enter key?

0 Kudos
Message 1 of 20
(6,647 Views)

You should use an Event Structure instead of polling the terminals.  You should just need an event case for the OK button's value change.  Put the terminal for the string inside of that event case to pass out its value to an indicator.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 20
(6,637 Views)

Max,

 

Can you post your code so we can see what you have done?


@max_ wrote:

 

If I add <Enter> to the toggle section, I am able to close the dialog box by pressing the key, however, the vi outputs the default value and not what the user entered in the input control.

 

How do I let the user enter a value and both close the dialog and accept the entered value with a single stroke of the enter key?


The VI I attached is a very rough example of what you might want to do but it did seem to exhibit the functionality that you wanted.  I was not able to replicate what you saw though, which version of LabVIEW are you using?  If you post your code we can take a quick look to see if it is something you are doing wrong or if it is potentially a bug.

Matt J | National Instruments | CLA
0 Kudos
Message 3 of 20
(6,608 Views)

@Jacobson-ni wrote:

Max,

 


The VI I attached is a very rough example of what you might want to do but it did seem to exhibit the functionality that you wanted.  I was not able to replicate what you saw though, which version of LabVIEW are you using?  If you post your code we can take a quick look to see if it is something you are doing wrong or if it is potentially a bug.


Matt, I sort of, hate the existing dialogs.  For several reasons I keep a set of prompts in my re-use simillar to this:

Prompt(DBL).png

NOTE: this does handle setting key focus properly This one is set-up to prompt a user for seconds minor teaks to the data type and/or display format can generate a "Prompt User For (Just about anything)"

 

Limitations:  No support for growing the buttons or dialog if the text is long: (Limited localization support included) I historically provide English only solutions.


"Should be" isn't "Is" -Jay
Message 4 of 20
(6,600 Views)

Numeric control only accept the value once the user clicks outside or removes focus in some other way. Depending on the type of input, you could use a string control set to "update values while typing" and "set to single line". When the user presses enter, you can scan the string contents into a numeric and only close the dialog if the value is legal.

 

I agree with tim that an event structure is better. Just close the dialog on a value change of the numeric control (this gets fired when the user enters a value and presses enter), don't assign key navigation to any buttons!

0 Kudos
Message 5 of 20
(6,589 Views)

I agree with altenbach agreeing with crossrulz (cough) about the event structure, but I disagree about using the Value Change event.  IMO, the window closing by clicking outside the control, but not on the OK button is not a typical UX.  And what about hitting the increment/decrement buttons or up/down arrows, should that also shut down the dialog?

 

I typically set the key navigation for the OK button as usual and also use the Key Down event for the numeric control to catch Return or Enter and will use that as an alternative to close the window.  In essence I am simply "forwarding" the enter/return keypress to the ok button.

 

Message 6 of 20
(6,569 Views)

Why should I use an Event structure if NI does not?

 

I'm aware of the benefits of events over polling/busy waiting and am using event structures whenever possible.

If this is a good practice, why is the express vi not following it?

0 Kudos
Message 7 of 20
(6,533 Views)

I downloaded your example vi. It looks pretty similar to what I have.

I only have 1 input and set its value after the init node isntead of the "open FP" node.

 

The problem persist.

Using your example vi.

I run the vi.

I enter the number.

If I hit enter, the value in the output "Input 1" is 5.

If I click ok with the mouse, I get the number that I entered in the dialog box.

 

I use LV 2013

 

prompt user input.png

0 Kudos
Message 8 of 20
(6,525 Views)

@max_ wrote:

Why should I use an Event structure if NI does not?

 

I'm aware of the benefits of events over polling/busy waiting and am using event structures whenever possible.

If this is a good practice, why is the express vi not following it?


I had a little discussion with NI about that.  Essentially these dialogs existed before the event structure and have not been "Cleaned up" yet.  It is a bit risky to prove use all cases opererate identically when modifying a core library component.  The Author of the code actually agrees that it needs to be cleaned up and migrated to Event based code.


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 20
(6,508 Views)

that makes sense, thank you for sharing your insights

0 Kudos
Message 10 of 20
(6,457 Views)