OK. (Deep breath)....If you use InteractiveChange or ProgrammaticChange, you are placing behavior into the control itself or, if you can abstract well, into the class the control is based on, right? However, the data source (or entity) may have it's own business rules and whatnot that require custom processing. If you can place this entity in it's own object and map the controls to the object peoperties (attributes), then you can use A/A events in the object itself to kick off behavior appropriate to that object while leaving the UI blissfully unaware and unentangled.

>>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?
>
>Ahhh, No I don't see :-( If ya' don't mind, run that one by again.