Using a String control with Enter, Return *and* allowing for repeated identical input

[paulwb]

Hi all,

There must be a simple solution to this, but it's Friday afternoon and my brain isn't cooperating.

I am creating a simple terminal by means of which a user can interact with an instrument. My question concerns the Query String control only. The Send button and the Terminal Table are there for reference.

Here is my desired behavior:

a) The user types a command into the Query field and types Enter or Return. An Event fires and the query is sent to the instrument. The focus remains on the Query field.

b) With no other UI actions, the user types Enter or Return again and again, firing an Event that sends the query to the instrument each time Enter or Return are typed. The focus remains on the Query field. 

Here's what I've got:

This achieves a), but fails at b). The reason is, since the value of the Query field has not changed, the Value Change event does not fire when the user starts spamming the Enter or Return keys. There is a way around this, as suggested by this post. Here's the solution in a nutshell:

Instead of looking for Value Change of the Query control, the event fires on every Key Down event of the control, and looks for an Enter or Return keypress. This catches the user action even if the contents of the Query field have not changed. The problem with this approach is that when this event fires, I need to read the value of the Query String control and send it to the instrument, but the value I obtain via the Query Local Variable is the old value, presumably because the Key Down event fires before the value of Query is registered as changed. Is there a way to programatically "enter" the contents of the String control so it is registered as a Value Change, before I query it via a Local Variable? Is there a different way I should be going about this? I'd rather not do anything that tied the Enter or Return keys to this particular field, since I have plenty of other UI elements that need these keys in my program.

Alternatively, is there a way to make the Query String control "Value Change" event fire when the user hits Enter or Return even if the value has not changed? 

Thank you for your input!

[ijustlovemath]

I may get blasted for suggesting this, but have you tried building out a state machine that mimics this behavior, with this main event structure in the "initialization" state and a second one (with NO overlapping events!!!) in the "repeat query" state? That may give you the behavior you desire.

[tst]

Your easiest option is probably to read the value of the control after the event structure, because by that point LV has updated the value of the control, but that won't affect the value change situation.

The other option is to only use the Key Down event, but to right click and check the update value while typing option on the string, which will change the value in the terminal with each click. The value inside the event structure will still lag by one event, but since you want the Enter value to terminate, that should work for you.

[paulwb]

---

@ijustlovemath wrote:

I may get blasted for suggesting this, but have you tried building out a state machine that mimics this behavior, with this main event structure in the "initialization" state and a second one (with NO overlapping events!!!) in the "repeat query" state? That may give you the behavior you desire.

---

My Event structure already sits in the "Wait For Event" case of a state machine. To make sure I understand: You are suggesting that I use the method b) I outlined above, triggering an event on every keypress in the Query control, and if Return/Enter were pressed, THEN transition to a different state, where the value of the Query control is read by local variable? By that time the control's value will have been updated to the new user-entered value (after the Enter/Return keypress). 

Ok, I'll give this a shot to see it it works for me. This might be the simplest approach.

[paulwb]

---

@tst wrote:

Your easiest option is probably to read the value of the control after the event structure, because by that point LV has updated the value of the control, but that won't affect the value change situation.

---

Ok, looks like a similar suggestion to the previous one, and it makes sense. The easiest way to do this is to use the Event structure to send my state machine to a specific Query state, which will read the updated control via local variable and send it to the instrument. I'll try that and report back.

---

@tst wrote:

The other option is to only use the Key Down event, but to right click and check the update value while typing option on the string, which will change the value in the terminal with each click. The value inside the event structure will still lag by one event, but since you want the Enter value to terminate, that should work for you.

---

Hmm. Having trouble following this explanation, but I will give it a shot and report back.

[ijustlovemath]

This is what tst is referring to. When this is active, an event is fire with every keystroke on the control.

[paulwb]

---

@ijustlovemath wrote:

This is what tst is referring to. When this is active, an event is fire with every keystroke on the control.

---

Thank you, I was referring to the statement that the value inside the Event terminal will lag by one command. In any case, I've figued it out: see next post.

[paulwb · Accepted solution]

I figured it out. 

1) The String control (Query) is set to Update Value while Typing.

2) Register the Key Down event for the String control. If Enter or Return were pressed, send the state machine to the "Send Query" state.

3) In the "Send Query" state read the value of the String control via Local Variable.

This has the desired behavior of allowing the user to hit Enter or Return over and over to repeatedly send a command, and the user can also type in a new command and send it by hitting Enter or Return. 

Thank you to all who helped me think this through!

[ijustlovemath]

No problem! I'm going to save this thread for a later date; I feel it may come in handy some time soon 🙂 BTW, minor style point. Instead of showing VI labels, you should use the VI Icon editor to make a descriptive icon. I usually just put some text on it, but you can also search for glyphs to make it fancy looking. Good luck!

[paulwb]

---

@ijustlovemath wrote:

No problem! I'm going to save this thread for a later date; I feel it may come in handy some time soon 🙂 BTW, minor style point. Instead of showing VI labels, you should use the VI Icon editor to make a descriptive icon. I usually just put some text on it, but you can also search for glyphs to make it fancy looking. Good luck!

---

Thank you. I usually skip icons unless it's a large project and I have time to work on the details. This one didn't get much time allotted to it, so I am just using VI labels for identification. I actually prefer it, honestly, given the size and scope of most of my projects. I've had to deal with some godawful garish icons that someone else thought were a good idea in some legacy code and that's partly why I don't rush to make icons myself. I did take an inordinate amount of time and care to make a toilet icon for a Flush Comms VI during my first LabVIEW project, however...

p.