>>>>>>There's no AddObject() function in VFP. I guess you're refering to NewObject() and AddObject() methods. If that the case than NewObject() method is very similar to the NewObject() function and AddObject() method to the CreateObject() function.
>>>>>
>>>>>Sorry, I was referring to the methods. Any relevant difference between .AddObject() and .NewObject()?
>>>>
>>>>The .AddObject() and CreateObject() rely on SET CLASSLIB and SET PROCEDURE (non-visual classes) to find a class to instantiate. The NewObject()/.NewObject() allow to specify a class library/.FXP as parameter.
>>>
>>>So why ever use AddObject() again? Why not always use NewObject(), as it seems more flexible?
>>
>>The most flexible of all approaches is the object factory. We always have to balance performance against programming time.
>>
>>http://weblogs.foxite.com/andykramek/archive/2007/08/04/4508.aspx
>
>In Tamar's response she noted that one approach is to SET CLASSLIB to all your VCX's up front, then you don't
>have to worry about it later. I use this approach and it has served me well over the years. Of course, this
>assumes that you don't have duplicate class names.

Yes indeed! However, things aren't always that cut and dried. Do you need all the classlibs open? What about parts of the program that are dependant on which user logs in? Etc. :)

If we had some kind of object - perhaps a classlib manager - and a factory, they could work together to dynamically load classes, per user - perhaps, either all upfront or on demand.