>>If you are going to refute my theory, please do so with facts......

Theory: a proposed explanation whose status is still conjectural.

How can you ask for facts when your argument is not based on foreseeable facts. I won't get into that discussion, but we all know VB is not VFP or viceversa.

I will present my theory too: It may be harder to make VB full OOP because of its object-based approach on language elements. Let's take the error object for example: it's already there, but since it does not support inheritance and it would be a requirement to make it sub-classable, it would require a rewrite. We as developers know that it's hard to understand somebody else's code when a rewrite is on the table.

With FoxPro what they did is they built most of that functionality as new features. No OOP-ing of XBase language elements. No rewrite. I don't know for a fact, but considering the differences in the end product between the FPW screen designer and the one on VFP I would guess things like that were built from scratch.

>First rule of debate... stick to the facts.
>Second rule of debate: Know and understand the points your opponent is making - and attack those - not the points you think he is making...
>
>Third rule of debate: If you are going to bring in supporting evidence for your rebuttal - make sure a logical basis of conlusion can be drawn. Anybody can pick stuff out of the air and make them into facts. Politicians do this all of the time.

You insist on setting the rules around here. I think I'll give myself half a point on your second rule and a full one on the third.
At least in my own mind. See the problem with your rules? The only rules I follow here are the ones set by the UT.