>>>>>David,
>>>>>
>>>>>I repspectfully disagree with my colleagues. If the defined behavior of the control is to change the form's property then that is what you should do. To do otherwise, for whatever reason, introduces an interdependency between the controls and the form.
>>>>>
>>>>>Future revisions of the form may cause you to change or remove the control that is bound to the property. This would cause code in a seemingly unrelated control to then fail. If the second control updates the form property and then refreshes the form, there is no interdependency between the controls and future modifications won't have the same impact.
>>>>
>>>>That's a tough call Jim and I agree with your reasons. A full form refresh may have some significant overhead in some situations. But I know your philosophy is 'do it properly, work out performance issues later only if necessary' - or something close to that, right?
>>>>
>>>>I wonder what others have to say on this. Thanks for the insight.
>>>
>>>Jim's approach is the correct implimentaion of oop principles. To a avoid refreshing the whole form, use an assign method (also called a mutator) to change the property. The assign method will know which controls need to be refreshed.
>>
>>Now I'm all ears Albert. Can you expand on this for access/assign dummies like me, perhaps a simple example?
>
>You create a methods in the container like getProperty() and setProperty() or you use vfp 6.0 check the Acess method and Assign method checkboxes in the add property dialog. The first technique requires you to call the method explicitly. In the second technique, the method call is performeded automatically for you when you access (? o.Property) or assign (o.Property = "value") to the property. Many OOP languages like C++ and Java only support the first technique, but Delphi and C++ Builder support the second technique.

So then in the assign method of the form property, which is being changed by an independent control, you say 'thisform.myobject.refresh()' ?