>>>>>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.
>>>>
>>>>Well, you don't have to refresh the full form... Also, you could create a thisform.color_assign method that checks for your class that displays the color, and if it exists, refresh it...
>>>>
>>>>BOb
>>>
>>>Hi again Bob,
>>>I think Jim implied that any firm link between two objects in this way is undesirable, so a form refresh is the go. If I simply refresh the other control then I may as well update the control value rather than the form value.
>>
>>Just to play devil's advocate- isn't refreshing the entire form overkill for this?
>>
>
>>If so, then the logical conclusion would be to refresh the single control that is bound to the form. To refresh that control, you have to know it's name, and that is the same type of object dependency Jim was advising to avoid.
>
>Exactly my point. I just didn't express myself that well. I try to avoid unnecessary refreshs because I find they do have a significant performance hit.


Hello all,
First off I agree with Jim, having one control change the value of another introduces an unnecessary dependency between the objects.
That being said, I can think of one way you might limit the performance hit. You could place the related controls in a container and call the container's Refresh method via This.Parent.Refresh() in the first control's Valid. You will take a slight hit from having the container but the Refresh will be limited to the controls contained within the container. Note that the only dependency that you have introduced is that the object that needs to know about the updated property is in the same container. More often then not I expect that this will be acceptable.
Just a thought,
Ned Ames