>Hey Jim
>
>>The factory that I use is data driven from a DBF. The DBF has filed for the Item name that I want to create and other fields that hold the classlib and classname that should be used. This way I can;
>>
>>

>>loFactory = Cretae("Factory")
>>loWait = loFactory.GetObject("MyPleaseWait")
>>* Now loWait is which ever class the factory data file says it should be
>>* I can change the form by changing the metadata and no code change is needed
>>* I cna mov3 the classlibs around as long as I update the metadata
>>

>
>That's one of the approaches I outlined. The questions I have revolve around the implementation matching the definition. In this case, your "client" is employing a data driven factory method patten, not an abstract factory pattern?
>
>Do you not lose a potential for decorating the MyPleaseWait by not using a MyPleaseWait factory as loFactory?

No, the factory is abstract because it has no idea about what it is going to create. The calling code doesn't know for sure either. The abstraction is into the metadata, which could be creating a simple class or it could be setting off a hook chain operation or virtually anything else. Also there is no specific personality to the factory, it is not "customized" for the PleaseWait operation rather it serves all object instantiation operations. I guess it all comes down to your particular definition of abstract, to me it means "non-specific to any operation" that being it is ultimately flexible in that it can deal with any situation at all from simple singlton objects to complexe heirarchies wihtout having any specific knowledge of what it is creating. Only the client knows what it asked for.