Enter as data entry terminator fails to trigger event handler

[altenbach]

Looking at your code in more details, you have some serious race conditions with undefined outcome. For example you are writing to the message string from two locations in parallel" (1) from the diagram constant on the left (2) inside frame 0 via a local variable. There is no way to tell which part executes first (and even if it now works correctly by accident it could change in upcoming compiler revisions).

Overall, you have way too many stacked sequences and local variables for my taste. None are needed.

Why do you explicitely close the panel in the last frame, the VI is set to close the panel automatically when complete.

[Mike_Powers]

---

@altenbach wrote:

Looking at your code in more details, you have some serious race conditions with undefined outcome. For example you are writing to the message string from two locations in parallel" (1) from the diagram constant on the left (2) inside frame 0 via a local variable. There is no way to tell which part executes first (and even if it now works correctly by accident it could change in upcoming compiler revisions).

Overall, you have way too many stacked sequences and local variables for my taste. None are needed.

Why do you explicitely close the panel in the last frame, the VI is set to close the panel automatically when complete.

---

Thanks for the tips, but this thread is not the place for them.  That bug demonstration program is the reduction of a much more complicated function that I made to demonstrate the LabVIEW bug.  The local variables and race conditions have no impact to the problem at hand, which I still don't have any answer to:  LabVIEW erroneously triggers the events in the incorrect order when the Enter key is used as a shortcut.

[JohnCS]

This is not a bug.  You are trying to do two things with the OK button with no data dependency between them. This can result in indeterminate behaviour under data flow. Without a data dependency, LabVIEW  always seems to do the opposite to what we expected.  

Changes in the Tester Name text are not detected by the string control until the text edit is complete and the string control is brought out of edit mode. Then the new text is entered into the control. Normally, this is done with the check box in the Menu Bar  or by clicking away from the control. The string control sees the Return key as a non printable character (\n).  But you have slaved the OK button to the Return key. When you hit Return, that key is read first and then the text change is now recognized by the string control. The OK Button case will go first because it was the first event that was detected. The Tester Name value change case will follow since the change was not acknowledged until after the Return key press.  Not what you wanted!

To overcome this, make sure that  Tools>>Options>>Environment>>"End text entry with Enter key" is enabled. Next, in the right click menu for the Tester Name control, enable Update Value while Typing. Now each time a key is pressed, it is entered into the control and will be detected by the Tester Name value change case. When you press the Return key, it terminates the text entry  and toggles the OK key sending control to the OK Button case second. If you didn't change the text before hitting Return or clicking OK, the Tester Name case is ignored.

JohnCS

[Mike_Powers]

---

@JohnCS wrote:

This is not a bug.  You are trying to do two things with the OK button with no data dependency between them. This can result in indeterminate behaviour under data flow. Without a data dependency, LabVIEW  always seems to do the opposite to what we expected.  

Changes in the Tester Name text are not detected by the string control until the text edit is complete and the string control is brought out of edit mode. Then the new text is entered into the control. Normally, this is done with the check box in the Menu Bar  or by clicking away from the control. The string control sees the Return key as a non printable character (\n).  But you have slaved the OK button to the Return key. When you hit Return, that key is read first and then the text change is now recognized by the string control. The OK Button case will go first because it was the first event that was detected. The Tester Name value change case will follow since the change was not acknowledged until after the Return key press.  Not what you wanted!

To overcome this, make sure that  Tools>>Options>>Environment>>"End text entry with Enter key" is enabled. Next, in the right click menu for the Tester Name control, enable Update Value while Typing. Now each time a key is pressed, it is entered into the control and will be detected by the Tester Name value change case. When you press the Return key, it terminates the text entry  and toggles the OK key sending control to the OK Button case second. If you didn't change the text before hitting Return or clicking OK, the Tester Name case is ignored.

JohnCS

---

Thank you for explaining why the unexpected behavior occurs.  Also, thanks for pointing out the "update value while typing" field can circumvent this problem.  However, I found things worked as I expected regardless of the "End text entry with Enter key" property value.

[JohnCS]

I am glad this works for you. You are right that End text entry with Enter Key has no effect in your case, but using it as a habit fulfils your original goal to have text entry behave like every other text entry program. 

JohnCS

[Mike_Powers]

Well, I tried to make a much more basic program showing this unexpected behavior (as I should have in the first place instead of the pop-up function with wrapper VI) and I uncovered another bug.  The program behaves differently with execution highliting on and off.

With execution highlighting on:
1) Enter Text in the box and click on OK.  The String event will trigger first.
2) Enter text in the box and hit enter.  The OK button event will trigger first.

With execution highlighting off:
1) Enter Text in the box and click on OK.  The String event will trigger, but now the OK button won't???
2) Enter text in the box and hit enter.  The OK button event will trigger first.

[JohnCS]

No bug here. Try changing the latch mechanical action of the OK button.  You'll see three different sets of behaviour.  Check out Changing the Mechanical Action of a Boolean Object in Help. You should be able to breakdown the button read and release sequences with a well placed breakpoint. Here's the sequence for Latch Until Released:

Wait > OK button pressed > text editor in string control is released by any click > String event detected > OK button change detected > OK event > OK button is read > OK button released > OK button change detected > OK event OK Button read > Wait

Your "no highlight, OK press" case acts the way it does under Latch When Released because the button releases when you leave the button to click the popup. The button is immediately released. This all happens in the String event case. By the time the event structure is called in the next iteration, the button is back to false and the structure doesn't see a change.

JohnCS

[Mike_Powers]

Yet another problem I have run into:

I now want to use a numerical control.  The "update value while tying" is no longer available.  Luckily I was able to figure out a workaround, so I am posting for others to see.  The problem is that the numerical control does not update until key focus is shifted from the control.  When using <enter> as a shortcut, it will change the value of the OK button WITHOUT shifting key focus so the numerical control is never read.  Therefore, I added a propery value to FORCE key focus to shift to the OK button before the numerical control is read, making it update properly AS EXPECTED.

I will still reiterate that this IS a labview bug.  When <enter> is used as a shortcut, the inherant behavior of labview should be to shift key focus to the control which uses it.  This is the expected behavior and I see absolutely no reason for anyone to argue otherwise.

[Kevin_H.]

I tried running your most recent bug example and did not see the non-updating behavior you referenced. On the VI you posted before that I did receive the behavior you talked and I agree it isn't entirely expected. When you click the OK button it shifts focus away from the text control which allows the value changed event to trigger. When the event triggers, the popup box shifts the focus away from the window which prevents the button event from triggering. This wouldn't be entirely unexpected to me if the button did not depress. I think it should either not depress, or it should depress and trigger the event. I believe the way it operates in highlight execution is much closer to how I expect.

Thank you for the detailed explination of that problem. Although I couldn't recreate what you described in your latest post, I'm happy to try again if you have another idea on how I can replicate it.