User | Kudos |
---|---|
13 | |
11 | |
3 | |
3 | |
3 |
Scenario:
A user has updated the value of a control in a window that has an OK button that will close the window. The controls are in a loop with an even structure. The OK button is set to toggle if the Return-key is pressed, and its change event will stop the loop. The user is happy with the state of every input in the window, including the just entered change, and hits the Return-key to OK the changes. The window closes...and the user later discovers that the last input he made, just prior to hitting the return key, never got registered...
The problem is that the Return-key does not trigger a change event for the active control *prior* to toggling the state of the OK-button. So if the OK button happens to stop the execution of the given VI, the last known value of the control that was active prior to the pressing of the return-key is not what the user saw at the time. People who use LabVIEW a lot get so used to this behaviour that they more or less unconciously click somewhere in the window with the mouse, or navigate elsewhere with the tab key to trigger an update, before they hit the return key. Everyone else get cought off guard.
Yes, it is possible to program around this problem by making sure that the toggling of the OK button does not stop the loop immediately but allows it to spin one more cycle just to make LabVIEW register the last control entry (or in the case of string controls, by setting it to "update while typing"). Adding such logic should not be necessary in this case though, it should be part of the in-built behaviour.
PS. Every time I run into this issue I feel like I must have overlooked or forgotten something. It cannot be true that this is not already handled automatically(!). I believe this problem was present even without the use of an event structure in some older versions of LabVIEW, or am I just getting senile?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.