03-09-2015 04:44 AM
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.
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.
03-09-2015 07:54 AM
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.
03-09-2015 10:15 AM
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.
03-09-2015 01:07 PM
@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 evaporates
03-10-2015 04:53 AM
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.
03-10-2015 10:39 AM
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
05-18-2015 07:26 PM
Interesting fact... if the second button is displayed you can use Enter for OK. See attached VI.
LV2013
12-11-2017 08:46 PM
12-11-2017 09:38 PM
@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
12-12-2017 12:01 AM
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.