Thanks! I guess that is why you are the MVP! 8-)

I was hoping this thread would lead to tying the A/A to data bound controls. Maybe the next version will fix the bugs with A/A?

>John, I disagree (as you probably would have guessed I would :-))
>
>Try this:
>
>Place two textboxes on a form, bind the first one to THISFORM.Tag. In that textbox, put THISFORM.Text2.Value = THISFORM.Tag in the InterActiveChange Event.
>
>Then run the form and start typing in the first textbox.
>
>Doing this, you'll find that the value of a property (or field) controlled by a control's controlsource will only change when the control loses focus, and not as the value changes.
>
>Furthermore, there's a small problem with Value_Assign methods: they don't work.
>
>To have code fire when the value of a databound control changes, there is no other way that I know of, then to put code in both the ProgrammaticChange and InteractiveChange Events. And even the ProgrammaticChange doesn't cover the control being assigned a value from its controlsource (an event that occurs ONLY with an explicit or implicit (after form.init) call to the control.refresh method.
>
>David-
>
>FWIW, all of my base databound controls have a method called AnyChange that is called from both the InteractiveChange and the programmaticChange events. When I need code to run every time the value of a control changes, I put it in the AnyChange method. Your current situation sounds like a prime candidate for this type of arrangement.
>
>>True, but that's not necessarily good design. You may have an object who's main role in life is to maintain attributes. If you want to wholly encapsulate function within this object, you want to couple it as little as possible to the UI and that is where Assign and Access come to play, but using A/A in the object itself and not in the front-end control, see?
>>
>>>You shouldn't need A/A here, we've already got InterActive Change and Programmatic Change in the base class, use those instead.