10-14-2010 12:53 PM
All,
With help from forum members, I figured out how to use the "Key Down?" event to send serial text when the user presses the "Return" key. Is there a way I can limit that function so the data is only sent when the cursor is in/over the correct text box AND the user presses the return key?
Many thanks.
Solved! Go to Solution.
10-14-2010 01:00 PM
Do you mean the mouse pointer needs to be over the text box, or just that the text box has focus? If the latter, then you can create a property node for the KeyFocus property of the string control. If that property is true, the string control is the current destination of any key strokes, and you can use that to determine whether to ignore or process the button push.
10-14-2010 01:24 PM
Thanks for your quick reply.
Wow, I really am a newbie at all this. I am trying to find an exact definition of "focus," but I cannot. If the mouse arrow is over a control, is it automatically in focus, or do you need to do something additional?
See the attached VI for an explanation of what I am trying to do. Any help is muchly appreciated.
10-14-2010 01:26 PM
I don't have 2010 installed, but if you can save it back to 2009 and upload that I'd be happy to take a look.
10-14-2010 01:28 PM
Is there an easy way to save the file as a 2009 file? Thanks.
10-14-2010 01:30 PM
Yes. File -> Save for Previous Version...
Focus means the control receives keystrokes. A control can get focus when the user clicks on it, when the user tabs to it (following the tabbing order set by Edit -> Set Tabbing Order...), or when the code assigns focus by setting the KeyFocus property of a control to true. There might be other unusual situations in which a control or indicator gets focus as well, but those are the ones that come to mind.
10-14-2010 01:32 PM
I done figgered it out, I think...
10-14-2010 01:33 PM
Ah! Thanks! Then, "Yes" I want the return key to trigger and event when the text control has focus.
10-14-2010 02:24 PM
You'll be most of the way there if you change the event that's handled to a Key Down event for the string control, rather than for the entire VI. That way you don't really even need to worry about key focus. You have the string control set to "Limit to Single Line" so the new line won't actually be added to the string but you'll still get the event.
The other problem is that you read the string value outside the event structure, so the value that you write to the indicator will be stale when it's written. The string value doesn't actually update until you hit the enter key. The event fires the moment you hit enter so it uses the value that's on the wire at that time, which is the value from before you hit enter, so your indicator gets an old value. There are several possible solutions. A simple but not necessarily good option is to set "Update Value While Typing" and assume that the user will always wait at least 10ms between the last keystroke and enter. Of course if you increase the timeout value you risk missing some characters, and there's not really a need for a timeout case at all in your event structure (just make a separate case for the stop button). Putting the string control terminal inside the event structure doesn't solve the problem - the event still occurs before the new value is processed - but, oddly, reading the value from a property node inside the event structure does work (although reading it from a local variable does not). You could also register a dynamic event that triggers the indicator to update based on the control. You could add a boolean shift register to act as a flag, and handle the value changed case for the string control as well. In the value changed case, if the boolean is set, update the indicator, and always set the boolean to false.
Sorry that's all rather complicated, there are quirks to LabVIEW's event processing. The easiest reliable approach is probably reading the string control's value from a property node inside the event case. While property nodes are not generally recommended, especially for getting or settting a value when the terminal is on the same front panel, in this case I think it's the least complicated solution.
10-14-2010 03:09 PM
That did it! Thanks for all your help! See functioning VI, below. If you think of any other ways to improve it, please let me know.