I would drop a container in the form and then all controls inside the container. That way they can be copied as a whole to another form.

That way logic that relates to a control is not hard coded, ie treeview or active x controls. You may have a class that can deal with 1 vendors control and a copy of that class to another vendors version of that same control. Now the parent class to that control is where all the direction is defined and all the control specific code is in the sub class of it.

__Stephen Russell
Memphis Visual FoxPro Users Group


>>Yes, a container (the form) has knowledge of what it contains. The contained objects (the controls) have no knowledge of eachother. The container mediates between the contained objects.
>Hello Albert,
> Using the form as a meditator is certainly more in keeping with oo design, but I think I see a drawback in your approach. If the form knows of the names of the objects that it contains you cannot remove these objects or rename them without changing the form's code. If you have multiple sections of code (say assign methods for multiple form properties) that refer to the same set of controls you must track down all the references and change them.
>
>If you decide not to track down and change the references then you must maintain all the assumptions of the code. if you wish to replace an object its replacement must have the same name. If you go one step furthur and make assumptions based on the class of the contained objects, for example calling the Requery() method of a contained listbox, you will have to ensure that any control that replaces the listbox also has a Requery() method.
>
>I think that maintaining either the code or its assumptions could easily become quite complicated.
>
> A few more thoughts,
> Ned Ames