>
>This is a very old argument...it was used way back in "the old days" as a reason not to adopt the tenets of structured design and programming. When someone states that "There are some problems that don't lend themselves easily to an OO solution," my usual response is, "Name one."
>
>Bill



Hi Bill,

Let me try, (and I think Dan is saying something similar).
This a real world case we have.

We have a FPW2.6 Application that is installed on 400 locations in 7 countries (all countries are separated by water, because they are all islands in the Caribbean)so we do not run around with our laptop.

This application is a payroll application (the .EXE IS 6 megabytes) and it produces many reports and official documents that are highly customizable (by us).
For instance (there are several things in this app that work like this): Clients sent a simple e-mail or fax with a layout of their wishes how their payslip should look like and we send them by E-mail a very small .FXP file that they copy to the program directory and a somewhat larger INVOICE.DOC file that they pay and that is it. The screens and programs in the applications are fairly complicated among other things because they are different per country.
Obviously I want as little as possible excluded from the .EXE to avoid all kind of problems.
This works terrific.

We will upgrade this app to VFP and we will go to OOP and we do realize all the terrific practical advantages of OOP and even the filosophical theory behind it. But in this case we reconsider.

Anybody has an idea what we should do in VFP OOP after I upgrade this app to VFP ?
Don't tell me to exclude the whole form class that calls the printing the payslip because that would be killing the fly with the elephant and not at all an option in this app. Besides, then I would need to keep a large library of classes for all this customized procedures.

Koos.