LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

I tried to use the ValueChange and also came to the conclusion that it is not what I want.

 

I wasn't aware of the issues you mentioned. I stumbled upon an even simpler one: one cannot accept the default value, because doing that does not cause the value to change.

I am not sure how I can filter out the Enter key properly.

 

I think the scan code is 43.

So I create a case that checks for 43 and does the regular things (passing the user input to the sub vi output). But it is a case structure which means I have to set up a stanmdard case.

I don't know what to put in the standard case. There is nothing to put in the standard case. I want to "do nothing", but data flow does not allow it. I have to pass some value.

 

prompt user default input.png

 

When I put a constant value there, the window closes immediately. Every key triggers the event but I only want it to trigger when the enter key is pressed, that means checking what key is press

 

Please explain to me how I forward the enter keypress.

0 Kudos
Message 11 of 20
(1,706 Views)

Keep you value in a shift register.  When some other key is pressed, you just pass the value that is in the shift register straight through.  In the case of the enter key, you pass out your new value.


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 12 of 20
(1,698 Views)

good idea with the shift register, thanks

 

I did not feel like using a shift register, instead, I solved the problem by forcing a value change.

I did this by creating a property node reading the value and writing that value back to another property node that is signaling.

 

On enter/return key event, I do the forced value change but keep the loop running.

On value change event, I stop the loop and output the current value.

 

I find myself doing this a lot in other situations as well.

 

Is there anything bad about this?

 

The problem I have with shift registers is that all cases have to shift the value through, which can be tedious if there are many cases and many shift registers.

It also creates a lot of "useless" wires, which reduces readability quite a lot.

0 Kudos
Message 13 of 20
(1,683 Views)

@max_ wrote:

good idea with the shift register, thanks

 

I did not feel like using a shift register, instead, I solved the problem by forcing a value change.

I did this by creating a property node reading the value and writing that value back to another property node that is signaling.

 

On enter/return key event, I do the forced value change but keep the loop running.

On value change event, I stop the loop and output the current value.

 

I find myself doing this a lot in other situations as well.

 

Is there anything bad about this?

 

The problem I have with shift registers is that all cases have to shift the value through, which can be tedious if there are many cases and many shift registers.

It also creates a lot of "useless" wires, which reduces readability quite a lot.


Yes that has problems.

 

The property node uses the IU Thread- a Shift register does not.  The UI Thread is a hard worker but really lonely and has no-body to help it.  Try to avoid dumping work on it that can be handled as well or better by any other worker in the office pool.

 

As far as the tediousness of wiring the Shift Register through multiple cases...... Well, Look into the help file YOU CAN Automate that! and your objection evaporatesSmiley Wink


"Should be" isn't "Is" -Jay
Message 14 of 20
(1,673 Views)

Good to know that in case I have to do optimization.

 

Is there any other way to cause the value change event to fire?

 

Automating the task of wiring helps getting the job done for sure, but I find that the result is still undesireable: many wires that don't do anything except for the one case that actually modifies the value.

Everything depends on everything else. I feel that the shift register aproach forces me into bad code, which is why I would prefer to cause the value change event case to happen programmatically.

 

 

 

0 Kudos
Message 15 of 20
(1,650 Views)

There are exactly two ways to get a Value Chane Event

 

User interaction:  (But that is the point, Users do things and events are generated so the code can do what the user expected if he read the requirements right)

 

Write to the property Value(Signaling): Not as nice... you can usually avoid it 


"Should be" isn't "Is" -Jay
0 Kudos
Message 16 of 20
(1,636 Views)

Interesting fact... if the second button is displayed you can use Enter for OK. See attached VI.

 

LV2013

 

test_prompt_with_without_cancel.JPG

Message 17 of 20
(1,554 Views)

Ran into this problem whilst writing a quick VI today and also noticed that "Return" was bound to Focus and Toggle on "OK 2" - removing this binding and rebinding the same settings to "OK 1" allows using the Enter/Return key in the way desired.


GCentral
Message 18 of 20
(1,045 Views)

@cbutcher wrote:

Ran into this problem whilst writing a quick VI today and also noticed that "Return" was bound to Focus and Toggle on "OK 2" - removing this binding and rebinding the same settings to "OK 1" allows using the Enter/Return key in the way desired.


Pop a zip

 

I'd like to check it out


"Should be" isn't "Is" -Jay
0 Kudos
Message 19 of 20
(1,039 Views)

This example project should show the behaviour. I added comments to the subVI diagram to describe the process I used.

 

The project was created in LV2017 32-bit, and the zip includes a folder backsaved to 2014. I haven't tested the backsaved version.

 

The calling VI just displays the values in indicators to demonstrate they are set appropriately.


GCentral
0 Kudos
Message 20 of 20
(1,030 Views)