>> Are you saying the screen updates are all conditioned by the Activate event code (with the added line this.refresh() ??<<
What I like to do is put the refresh code for each control into the control itself, in the Refresh(). Not in the container like you are suggesting. This way the Activate code is simplified to one line: This.Refresh() This one line calls the Refresh() of each visible object in the container, and subsequently drills down into all visible containers and calls the visible control Refresh(). When this happens I get the default behavior where VFP updates the .Value with the value in the .ControlSource. Now for the special cases where I have additional behavior as you describe, putting this logic in the control's Refresh() also gets called. I like that objects control themselves and are all knowing about themselves. It removes the interdependency created by coding in the one method. It removes the concern of when code is called, and understanding if the object is already instantiated or not. The drawback is you have to touch lots of objects if there is lots of refresh behavior that needs to change based on user requirements. It is a choice. Rick White Light Computing, Inc. www.whitelightcomputing.com www.swfox.net www.rickschummer.com _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/021301caa626$02cc6c40$086544...@com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.