>Hey Dragan et al
>
>An abstract factory is a factory that returns one of a set of common concrete factories to produce one of a set of common concrete classes.
>
>http://en.wikipedia.org/wiki/Abstract_factory_pattern
>
>To the best of my understanding a data driven factory is still just a factory. It is not an abstract factory.

Somewhere upstream of this thread (and in the parts you quoted here) we had explained why we don't need the distinction between an abstract and concrete factory in a VFP data driven factory.

>http://en.wikipedia.org/wiki/Factory_method_pattern
>
>What's the benefit of an abstract factory? AFAIK, it lets me order a car from a dealer. The dealer provides the car based on my requirements. They then decide which make and/or model to send me.
>
>If I want to order ice cream, I need a different abstract factory.
>
>I built a data driven factory, but what it does not give me is the ability to customize the end product.

Why should it? The factory is a factory is a factory, it gives you a product you ordered. If you wanted modifications of the product - you have several ways to do it:

- create a different product
- add a method to your product to customize itself and pass it some parameters to tell it what you want
- run a decorator pattern on your product and have it modify it the way you want

>I used the factory to create a container. I can change the entry in the table to specify which container. I can even change the table name in the factory class to have it create different classes. That's neat.
>
>This container needs 2 buttons, search and clear. The init can call a pair of methods of the container that use the data driven factory to drop on the two buttons. That's neat. However, I think it's not as flexible as it could be.

Me too. I think the container should have a method, say .AddButton() which would do that. Then you wouldn't need to change your factory across the board just to be able to customize your container. You'd have your standard factory and a container which knows what to do.

>The two buttons are similar concrete classes specific to this search container. So, I should have an abstract factory to return the search button OR the clear button (via their respective factories). Their factories are a good place to control the appearance of the buttons.
>
>So the abstract factory would need a parameter tcButtonType. Based on that it would instantiate the right factory. That factory would instantiate the right button (still can data drive it) and then customize the button.

This is where we part. IMO, you need just one factory - not specialized, not overloaded with parameters. You may pass parameters to the init of whatever product the factory makes, or you may call the product's methods once it's made, and that's pretty much all you need, without creating a dozen factories for each category of objects.

>Common functionality would exist in the button classes, controlled only by properties set by the factory - since it is difficult to dynamically write and test code in the buttons.
>
>I'd like dictionary perfect examples to increase my understanding of the design patterns. If I'm right in my current thinking this is a very flexible way to go and it's not that difficult to put together.
>
>A better example would be a customer form. I think I could now completely customize the customer form from a single class into any number of different applications, without subclassing.
>
>Does that seem right to you?

I think you got the right idea, just trying to put the code in the wrong place. IMO, the beauty of the factory pattern is in its simplicity - and the ease with which it introduces a level of separation between the alias of a class and its physical location (class name, class lib or prg), specially in the VFP data driven factory. I've even seen a factory with two tables - global and local, where local would be searched first and would be customer specific. The global would hold the default classes for the whole app and would be distributed for all the customers. And this factory had just about 200 lines of code.

Again, the inability of C++ to instantiate an object from its class name passed as a string (i.e. the need to have the name hardcoded somewhere) brought the need for concrete factories. VFP doesn't need that - factory is a factory is a factory.