>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.

If it's a report, you may want to encapsulate the .prg which ran the report in FPW into the .frx itself, so you can send just the .frx/frt. Or you may want to have standard forms as classes, and local forms as .scx/sct instantiated from these classes, and have their names somewhere in the tables. The tables should contain the name of the standard form (which may be included in the exe) or a name of a localized form. This way you have a hook to plug local versions of anything you may want, and the local versions are just subclassed from standard versions.

How does this sound in your layout?