Odd UI event behaviour

[crelf]

Tell me I'm going crazy: have a look at the attached VI. It's purpose to to warn the user that an error has occured, and require a password to continue. I created the attached VI (it's not complete) with an event structure in it. OK - so I'm having two issues:

• If you enter a password and the press "enter", then the value present at "Entered Password" is the value on the previous loop. For example: the first time you run it, enter "test1" in the password field and press enter. When the event fires, the value read from the password field will be "". Now, type "test2" in the password field and press enter. When the event fires, the value read from the password field with be "test1". (note: this problem does not occur if you click the "continue" button - only if you press "enter" which is bound to teh "continue" button through key navigation. OK - now enter "fred" (that's the correct default password) and press "continue" - you get "Incorrect Password". Go ahead and press "continue" again - voila! Correct password and all is well.
  
• The "key focus" property in the loop doesn't always work - sometimes it does, other times it doesn't. I think this maybe because it tries to set the focus to this control while the "Incorrect Password" dialog is still active?
  Are these both cases of LabVIEW getting ahead of itself, or am I missing something? (I am feeling a wee bit weary at the moment, so I'm hoping it's something obvious I've missed... )
  

[TobyD]

QUOTE (crelf @ Mar 20 2008, 08:49 AM)

• If you enter a password and the press "enter", then the value present at "Entered Password" is the value on the previous loop. For example: the first time you run it, enter "test1" in the password field and press enter. When the event fires, the value read from the password field will be "". Now, type "test2" in the password field and press enter. When the event fires, the value read from the password field with be "test1". (note: this problem does not occur if you click the "continue" button - only if you press "enter" which is bound to teh "continue" button through key navigation. OK - now enter "fred" (that's the correct default password) and press "continue" - you get "Incorrect Password". Go ahead and press "continue" again - voila! Correct password and all is well.
  
• The "key focus" property in the loop doesn't always work - sometimes it does, other times it doesn't. I think this maybe because it tries to set the focus to this control while the "Incorrect Password" dialog is still active?
  Are these both cases of LabVIEW getting ahead of itself, or am I missing something? (I am feeling a wee bit weary at the moment, so I'm hoping it's something obvious I've missed... )
  

If you check "Set to focus on Toggle" it works. Not sure why though...

http://lavag.org/old_files/monthly_03_2008/post-8758-1206029956.png' target="_blank">

[B Chavez]

Set "Update Value while Typing" on the string control and it works fine. It seems that pressing 'Enter' fires the "Ok": Value Change event but the control has not been updated, it's still being edited.

[TobyD]

QUOTE (B Chavez @ Mar 20 2008, 09:38 AM)

Set "Update Value while Typing" on the string control and it works fine. It seems that pressing 'Enter' fires the "Ok": Value Change event but the control has not been updated, it's still being edited.

Ahhh, that makes sense. That would explain why changing to focus on toggle works too. Changing the focus would force the string control to exit edit mode and update.

The only way I could get the key focus property to work every time was to add a 1ms delay before the property node. That should not have to happen though.

[JDave]

QUOTE (B Chavez @ Mar 20 2008, 09:38 AM)

Set "Update Value while Typing" on the string control and it works fine. It seems that pressing 'Enter' fires the "Ok": Value Change event but the control has not been updated, it's still being edited.

I've run into this race condition before. The event structure can fire before the terminals are updated.

[B Chavez]

And with regard to the second question, adding a 'timeout' event allows the loop to run again and sets the KeyFocus as expected.

[TobyD]

QUOTE (B Chavez @ Mar 20 2008, 09:46 AM)

And with regard to the second question, adding a 'timeout' event allows the loop to run again and sets the KeyFocus as expected.

A timeout event will prevent focus from going anywhere else (at least not for longer than the timeout setting). If you ever need to "Cut and Paste" the error information for example, that could cause problems.

[crelf]

QUOTE (B Chavez @ Mar 20 2008, 11:38 AM)

Set "Update Value while Typing" on the string control and it works fine. It seems that pressing 'Enter' fires the "Ok": Value Change event but the control has not been updated, it's still being edited.

Of course! Thanks to everyone for their ideas :thumbup:

[ned]

QUOTE (B Chavez @ Mar 20 2008, 12:46 PM)

And with regard to the second question, adding a 'timeout' event allows the loop to run again and sets the KeyFocus as expected.

I rather like the timeout approach, with a twist - I keep the timeout value in a shift register that's normally set to -1. When an event causes the loop to exit I set the timeout shift register to 0, put my front panel terminals in the timeout case (unless they're used elsewhere, in which case they go outside the event structure), and let the timeout case stop the while loop. This allows all values to update and any pending events to trigger (and if one of those events needs to cancel the exit, it just resets timeout back to -1).