>>>Thank you. One thing I could never understand is the concept of "factory". How would you explain it in other words?
>>
>>A factory? Something that tells your code what to use. cClass in newobject and addobject need not to be hardcoded. It's a string and might be altered or read from somewhere.
>>
>>There are many approaches. Just an example.
>>
>>Think of the following
>>Instead of
>>

THIS.AddObject(cName, cClass [, cOLEClass] [, aInit1, aInit2 ...])

>>you do
>>

Factory._AddObject(cName, cClass, THIS[, cOLEClass] [, aInit1, aInit2 ...])

>>
>>now factory checks, for example from a table, if there is a replacement for "cClass" to be used. Depending on settings of your app, or a patch class depending on a patch issued, or debug state. Then Factory will run for the object send as parameter
>>

oObj.AddObject(cName, cNewClass [, cOLEClass] [, aInit1, aInit2 ...])

>>
>>Or you just alter the code of your base classes addobject to call the factory to return the altered class, and dodefault to instantiate the returned class. This is more easy - no fiddeling with datasession.
>>
>>You can do this on newobject or createobject as well.
>>Sooner or later one will handle anything through it, then the basic call will use a UUID for cClass, and any return is from the factory.
>>
>>google, there are some articles about it. I've not invented it myself ...
>
>Thank you. I am still confused. In your example, above, is Factory some kind of a class?

Picky me: No, the instance of a class.

ok. you need something, that figures out what class is to use for a given string.
This is something done over and over - for me even running a form from menu will call the factory.
Instantiating the form means with me: form, dataenvironment, cursoradapters, some hooks. Lot's of calls.
Normally this is a read from a table - or from a bunch of tables that need to be concatenated.
One will not do this openening / closing for each call, so it's just a session object that opens on app start. This is why I'm in favour of altering bases classes method.
The object is in it's own datasession and this might create odd results instantiating objects.
It is also offers different other stuff then simple return class for class, see below.
But there is nothing that stops you from just using a procedure.

Examples of use:
I re-use cursoradapter classes for different forms. So the dataenvironment asks the factory for an ordered list of CA's to instantiate. The DE has just a single string, and the factory returns an array.
I have a report pick form - the list of report-items for a given form is read from the factory. The frx's the user may select for an item is a returned .... ad nauseam
I have an app that deals with the more complex setting of this factory. I'ts grown over the years.