>Well, I guess it has a lot to do with RAD and using your own framework to write middle tier com-servers. For example you've got a class on a applic class wich makes new primarykeys. This class maintains a table with the last used primary keys split in categories. If for some reason a project requires character primarykeys i can subclass the applic class and make changes in the Primary generator object.
<

I understand the point you are trying to make here. However, in the scenario you describe, you should not have to make changes to the key generator code. If your class has an attribute that dictates the data type to be generated, your generator should then query the property to determine what data type to use. In the case of string keys, another attribute could indicate the length. Now, which is better? Creating a class hierarchy? Or, creating a class that both implements the key generator class, and sets some defaults? Even if I make changes to the generator code, I will still see them in my implementation, all without inheritance. This is why the rest of the outside world could give a lick about VFP's use and implementation of inheritance...

>Also I've got some general error handling routines which try to determine causes of errors and even try to solve it. Some of the errors are application dependend, some are not. When you try to adjust your middle layer, OOP might come in handy to handle the solution specific errors.
>

Huh??? Even in Fox 2.x, we could get this behavior. What you are referring to here are overriding generic behaviors in favor application specific behaviors. This is not in the domain of OO. We could do this with well written UDF's in the pre-VFP days...

>Another feature used in middle tier, is handling application security. I've got framework classes which take care of this. To have maximum flexibility to implement security It might be handy to use subclasses. If you want to use your own or Novell security data instead of the standard NT security subbclassing is a great mechanism to accomplish that.
>

Once again, I would not use inheritance for this. What you are really talking about here is defining a base interface with some base functionality, along with some various implementations (Novell vs. NT). If you look at how would do this in VFP vs. VB, I think you would find it would not be all that different.

>Unfortunately, I'm not that familiar with VB. I can't judge if another implementation just would ease the pain of missing OO. I'm only pointing out that OO can be of a significant value.
>

The scenarios you describe are not OO dependent. In fact, in the scenarios you point out, I would dare say that a reliance on inheritances is not desireable at all. When you start talking about middle-tier issues, you are going to be hard-pressed to find a situation where you would require a significant class hierarchy. Honestly, VFP's use of inheritance is most signficant on the UI, not the middle tier.