Hi Design Pattern Experts

I want to show a form. It basically says Wait, Please. So we can call it frmWaitPlease. I may want to use it as is, or subclass it. There is the possibility that the framework may also display frmWaitPlease. If I subclass frmWaitPlease to frmWaitPrettyPlease, I want frmWaitPrettyPlease to appear when I use it in my application AND anywhere the framework might call frmPleaseWait.

Now, I suppose I could create a frmPleaseWait factory class cusWaitPleaseFactory. I would have to instantiate that class by name. oWaitPleaseFactory = CreateObject("cusWaitPleaseFactory")

oWaitPleaseForm = oWaitPleaseFactory.Create("WaitPleaseForm").

That "WaitPleaseForm" string could be decoded via a table to get the real class name and instantiate and return an object reference. Now since the factory was instantiated in the current data session, new objects would participate in that data session (except for forms where the data session would depend on private or default data session).

Now, what exactly is the Abstract Factory pattern? Is an abstract factory a superclass of a concrete factory?

The UML is confusing to me:

http://fox.wikis.com/wc.dll?Wiki~AbstractFactory~SoftwareEng
http://www.dofactory.com/Patterns/PatternAbstract.aspx#intent

It looks like the Client uses the abstract factory to produce an abstract product. By definition, the abstract cannot be used. So does it mean the client has to instantiate one or the other concrete factory depending on the type of Concrete Product desired? Is that all there is to it? It's called the abstract factory pattern because there's a choice of which factory to use to produce a product? That's the confusing part. Abstract and Concrete seem to refer to a parent class and a subclass.

Now to implementation. I want a WaitPlease form.

oWaitPleaseForm = oFormFactory.Create("WaitPleaseForm")

If that code does a seek in a table, isn't that just a factory, albeit a data driven one? There's no decision about which factory to use.

However, this decides what factory class:

m.lcFormFactoryClass = oApp.GetFactoryClass("WaitPleaseFormFactory")
m.loFormFactory = CreateObject(m.lcFormFactoryClass")

and then this decides which product:

m.lcWaitPleaseFormClass = m.loFormFactory.GetClass("WaitPleaseForm")
m.loWaitPleaseForm = CreateObject(m.lcWaitPleaseFormClass)

That looks to me like the UML. My client code chooses which Factory to use to produce ProductA (subclassed from some parent product) and then a concrete factory subclassed from a parent form factory produces it.

That means I could update the table to specify my form factory subclass and my wait please form and they would be used everywhere, provided the framework also made such calls.

I'd get around the VFP session issue because the final object would be instantiated by the client in the client's data session. However, the factory did not create the object. Would it be good to pass the finished object back to the factory for decoration?

Thanks, hopefully that's not too much to chew on.