>Ed,
>
>Was hoping you would add your 2 cents worth -
>
>I thought of that and actually started to model it when I discovered that I could not name the instance of the class the same as the class it was created from (like you can with ADD OBJECT). This is not a big deal but I would like to use Application.User instead of Application.MyUser and I don't want to rename user to _user.
>
>How about the dependency issue? should I be passing the application object to the children objects as a parameter as they are initialized or should I freely use THIS.PARENT to reference the properties in the sibling objects?
>

The obvious question is can the object exist without having a direct parent? if yes, you'd best pass the parent reference in when AddObject() is invoked (you can always pass this as a parameter from the parent when adding the object via AddObject(). If you always pass a reference to the app object as a parameter, then it gives you the option of having an instance of the object exist free of the app object; if you've saved the app object reference from Init in a member property (like oAppObjectRef), then this.oAppObjectRef will work whether or not you app object is the direct parent, or simply exists somewhere else in the object space. An object reference depends only on the object reference being valid, not on the containership hierarchy of the current object. Both work. If the object doesn't make sense without the frame of reference of the application object, this.parent is pretty clear, and it doesn't cost anything to use...

>...tim
>
>>>David,
>>>
>>>I have experimented with this and although you can drop other objects onto a container I have not found how to control the order in which they are created/initialized. Am I missing something or should I not be designing my objects to depend upon a load order?
>>>
>>>For example I have created an application class and I have dropped eventlog, screen, environment, version, security and user instances onto it. These objects need to share information between each other that could be obtained when they are initialized if it were done in the right order otherwise I have to finish initializing the objects in the Init method of the application class by calling a seperate method in each child object (.User.setUser(),.Version.setVersion()).
>>>
>>
>>Why not add them through the AddObject() method in code in the Init method of the application class; something like:
>>
>>

SET CLASSLIB TO <i>whatever, where ever</i>
>>WITH this
>>   .AddObject('User','MyUserClass')
>>   .AddObject('Version', 'MyVersionClass')
>>   * pass the result of user.getUserID() as a parameter to the Security object
>>   .AddObject('Security','MySecurityClass',.user.GetUserID())
>>   * etc, etc, etc.
>>ENDWITH

>>
>>It ain't drag and drop, but it does the job and gives you perfect control.
>>
>>>I this is the preferred method then I can live with it but I am tempted to define my application class in a .PRG so I can order them as I like. What is you approach?
>>>
>>>...tim
>>>
>>>>Tim,
>>>>
>>>>The only real difference is if you are using the Class Designer you can not drop other objects into a Custom class at design time. They can only be added at runtime using the AddObject() method. Container derived objects also have a visual appearance at runtime whereas Custom does not.
>>>>
>>>>>While browsing various class libraries I noticed the use of the container where I would expect a custom class. Could you explain the advantage of this?