>>
>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?

The difference between these two approaches is in the PEMs of the contained object, specially its code. In the first example, you can have code for the label which doesn't exist in its class definition, ie. you can override and even add new methods.

DEFINE CLASS oC AS CONTAINER
  ADD OBJECT oL AS LABEL

procedure ol.click()
   messagebox("this is not in the definition of "+this.class)
endproc
ENDDEFINE

You're actually doing this whenever you change a method of any contained object in a visual designer (form or class); this is how it looks when done in code. Of course, you can have no code in any of the contained objects' events at all, and do everything by bindevent()ing to form's custom methods, but it sounds like an overkill - I figure everybody has some button with some custom .click() code somewhere. Well, you can't really do that if the button doesn't exist at design time - you'd have to .addobject() the button, bindevent() to its .click and have delegate code in the containing object.

>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'?

In a way it is more restrictive - you can't override any of its code except by bindevent() or by explicitly having that code in its class definition. OTOH, this means the contained object is developed separately, may be done in a separate classlib, by a different programmer etc - and there you have some degree of liberty that you don't have when coding it inside the containing object. So, it boils down to the question as old as OOP itself: where does the code go?

>But, IAC, like you I don't think I've come across a practical need to define a class on-the-fly...

I actually did once - had to subclass one importer so its import routine would skip the processing of fields absent from the imported textfile. The routine included calls for other methods of this class, so this saved me something like 40000 IF statements (on 1000 records). Sure this was a simple case, I wrote only one method :).