>>
>The difference between ADD OBJECT and .addobject() is that in the first case (and likewise, in an object you add in a visual designer) the added object becomes a member at design time, and there's room for its code - it can be edited (and in .prg case, new methods added, though I haven't tried that). All that becomes part of the class definition of the container (i.e. the containing object - which can be form, toolbar, container, page, etc). However, .addobject() adds an object from an already compiled class definition, i.e. there's no way to change it now. That's runtime adding.
>>
>
>I still don't see a difference between:
>

>DEFINE CLASS oC AS CONTAINER
>  ADD OBJECT oL AS LABEL
>ENDDEFINE
>******and:
>DEFINE CLASS oC2 AS CONTAINER
>  PROCEDURE INIT()
>    THIS.ADDOBJECT("oL2","LABEL")
>  ENDPROC
>ENDDEFINE
>
>DEFINE CLASS oL2 AS LABEL
>ENDDEFINE
>

>Assuming these have been fleshed out with properties/methods in either case the required behaviour must be known, and is fixed, at design time. Once instantiated how does an instance of oC differ from an instance of oC2?
>

differences:

- the init() sequence
- the ZOrder and TabIndex position
- as work .RemoveObject(): leave a Zombi with ADD OBJECT

>>
>However, .addobject() adds an object from an already compiled class definition, i.e. there's no way to change it now.
>>
>But, potentially, you can delay deciding on the implementation of "oL2" until runtime so surely it is less not more restrictive than using 'ADD OBJECT'?
>
>But, IAC, like you I don't think I've come across a practical need to define a class on-the-fly...
>
>Regards,
>Viv