unexpected event structure behavior

[smercurio_fc]

---

Darin.K wrote: 

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. 

---

The only reason why it was the same in this case was the the control initially had a blank value. Hence, when you put in an invalid entry followed by clicking outside, you got the Value Changed event, and it just so happened that OldVal = NewVal = "". I still don't see this as a bug, but rather as expected behavior, despite the brief discussion here, and the points raised.

[SteveChandler]

It is expected by me now. But before I would have expected the event to fire when the value is changed from the FP users perspective. I knew that string controls would behave this way and I know that the combo box is just a fancy string control. But nothing gets updated visually in the combo box and the system beeps an error when you try to enter an undefined string. It is not surprising that people would not expect a value changed event. But it definately makes sense.