>I suspected this was the basic functionality. Looks like value prop holds the intermediate value as the user is typing in new characters then ENTER triggers the event that synchronizes the value prop with the controlsource.

It is not the ENTER that forces the update but a point in the process of the control losing focus (however that may happen, enter, tab, mouse click, SetFocus call in code etc..)

>I find it interesting that the controlsource is synchronized to the value property just before Valid fires. It seems like you'd want to hold off on revaluing the controlsource until you actually check to see if the new value is in range. It's pretty conventional to leave the original value of a variable unchanged if the requested new value is out of range. So, how would you do this in a Valid method if the controlsource (and therefore the old value) has already been overwritten?

We could argue this all day, but it wouldn't change the way it is. I actually would like it the way you suggest , that the update occur only if the valid is successful just before the LostFocius() fires. Unfortunately, that isn't how it works though. I doubt this is anything that will change as developers write code that depends on this behavior and so it is diffficult to change it without breaking existing code.

>BTW. I just discovered the Assign and Access methods for properties and have successfully used the assign to validate a property I was using as a control source. Seems to work great, plus, I have access to the 'old' value of the property just in case I want to retain it in the presence of an illegal new value.

Assigna dn Access methods can be very powerful features, but they can also be overused too. Keep in mind that using an assign or access method slows down access to the property. If it is a property that is being read or written many times, then you may not want an access or assign method on it for performance reasons.