unexpected event structure behavior

[slipstick]

Attached is a snippet (2009) that is not behaving as I expect. You can try to type in an entry in the control that isn't in the pull-down, then click out. There will be no visible entry in the control, but the event structure runs anyway. Is this expected? I had to add code to a VI to account for the event case running even though there was no entry in the control.

[smercurio_fc · Accepted solution]

First, the delay in the loop is not necessary with the event structure. The event structure will not use up CPU time unless there is an event.

As for the "value change", that's a bit debatable. Technically, there is a value change. It's just that the control value is being changed twice. Once to receive the disallowed letter, and then again when the higher-level restriction says "no-no", and changes it back. I'm not sure at which point the event is being generated, as that would be in the bowels of the event generation code that we don't have visibility to.

[slipstick]

Thanks. I've had code randomly giving me false blank or default entries for years and never knew why.

Yea, the timer is an old habit.

[SteveChandler]

Interesting. When this value change event happens OldVal and NewVal are equal. It seems that you have found a bug. Or maybe a feature. You can check if OldVal=NewVal and have an event for when the user tries to enter something undefined. Weird.

[SteveChandler]

---

@slipstick wrote:

Thanks. I've had code randomly giving me false blank or default entries for years and never knew why.

Yea, the timer is an old habit.

---

You probably already figured it out but to get rid of the false blank or default entries just compare OldVal and NewVal and put your code in a case structure.

[slipstick]

I guess if there is a way to apply this, we could call it a feature. If it can't be applied to anything, it's a bug. 

[SteveChandler]

Ok here is this bug as a feature. Press a key that is not allowed then click away from the control.

[Darin.K]

Apologies in advance, I do not have LV here to test, but based on reading the replies I feel like something is missing here.

With the Combo Box, clicking outside the control is like hitting enter, the check mark button, etc.  It will fire the Value Change Event even if the value is the same.  This is true for all controls.  It is more of a Value Entered event.  Pressing Escape is the proper method to cancel the entry.

If you enter an invalid string by clicking as described, the value will be empty and the Value Change event should fire.  This should be reflected in NewVal="".  OldVal *should* be correct, is it not?  Doing it twice should give you OldVal=NewVal="", but not the first time.  I am almost certain I would have seen this bug if it actually exists.

In short, I expect that entering an invalid string will fire the Value Changed event.  I do not expect OldVal to equal NewVal unless an invalid entry (or the same valid entry) was entered twice.  Does it really on the first try with an invalid entry (valid followed by invalid)?  I say check for NewVal="" and if so either complain to the user or write OldVal to the ComboBox Value property or local variable. 

[slipstick]

Darin.K,

For my snippet, I supplied indicators for old and new values. I then ran it, and tried to enter an invalid entry such as 'q'. Then I clicked out. Both old and new values were "". See attached.

[SteveChandler]

Good observations Darrin! I posted a link to this thread in the appropriate place