Hi Mark,

We're talking about two different definitions of the same term. Like asking, "What's the weather like?", the response is colored by our own particular definitions of what "nice" is. This is, therefore, something that's not subject to any meaningful debate. You choose, as is your right, to apply a rather precise definition. I, on the other hand, and as is my right, choose an abstract one.

This choice is colored by my belief that abstraction is one of the most powerful tools, if not the most powerful, that we can bring to bear on any problem.

However, you did pose a question or challenge, and I feel obiliged to respond.

Now, I should point out that OOP, regardless of definition, cannot be hinged on whether or not an object happens to be visible. Many ActiveX controls aren't visible, and neither are any custom classes. So the state of that particular property is wholly irrelevant.

Now let us assume the following: We have an FP 2.x (DOS or Windows) application. Further, let's assume that we have an executable called parent.exe. This program contains menus and dialogs which are designed to be generally used by an application. Let's also assume that we have and application, called child.app. If parent.exe has a procedure file that's initialized on load, can't child.app call a procedure or function within parent.exe ? Of course. Does the code have to be complied within child.app? Of course not. Yet whenever a change is made within the parent.exe procedure file, doesn't the child.app "inherit" those changes? Of course. The procedure file doesn't even have to be included in the child application. It is, however, a good idea do so to avoid erroneous compile time errors. It can, however, be marked as excluded. This way, none of tokenized code is included with the compiled executable, which may be turned over to the user, without the necessity of re-compiling the child application.

Further, should the parent exectuable contain a menu with options not included in the child, these can affect the behavior of the child's objects as well. For example, a dialog to manipulate the record pointer in the current work area could be included in the parent and called from a menu within it. It would not necesarily have to be included in the child application, nor would the child application even have to be aware of its existence. Yet, if any changes were made to the dialog and the new exectuable call the child, the child would immediately "inherit" the changes.

The difference is that these changes occur after compile and not during design. To me, that a perceived difference, and one that is totally irrelevant. Learning to differentiate between perceived differences and real ones is one of the keys to effective design.

Finally, the above scenario is not a hypothesis. I have done exactly as described above since FPD 2.0.