>I'm not sure why you brought web services into the discussion.

I am trying to ascertain the basis of your "forward-compatible" theory. I had thought your foward compatibility direction was pointed toward .NET - not within the VFP world itself.

Because you did not mention Web Services, I was a bit perplexed? That is why I asked the question. As you will see, your argument would have been better served had you gone down the web services road. It still would not have been great because foward-compatibility is a logically flawed concept..

>
Take 100 random VB6 apps and try to run them in VB7 without any conversion, or even with the built in converter (but no other programming.) Do the same with 100 random VFP6 apps running in VFP7.

As far as I know the VFP6 apps will generally run in VFP7, though there have been a few bug fixes which change a few things.
>

You mean VB .NET? AFAIK, VB 7 does not exist....< g >

All kidding aside, this is like lobbing a 75 MPH pitch to Barry Bonds or Mark McGwire.

Where do I start....???

1. There is a fundamental paradigm shift between VB 6 and VB .NET. I compare
it to Fox 2.x > VFP. Nobody in their right mind would run 2.x code in VFP
as is. At some point, modifications are required. The same is true between
VB 6 > VB .NET. Using your logic, FPW was forward compatible with VFP.

2. Assuming that code running in VFP 6 does run unchanged in VFP 7 - so what?
Advantages without tangible benefits are worthless. The benefits I am
looking for would drive somebody who does not use the product to all of a
sudden, use the product. Forward compatibility, assuming such a concept
exists - necessarily precludes anybody who doe not currently use the
product.

3. Forward compatible is an illogical premise. To be forward compatible, it
means that the day software ships, you can identify forward compatibility
as a feature. The fact is, you cannot. The only thing you can identify with
certainty and make a feature is backward compatibility. In the scenerio you
describe, VFP 7 is backward compatible with VFP 6. The logic does not work
in the opposite direction because you are comparing apples and oranges.

At best, forward-compatibility is an after-the fact concept. Still, is
VFP 6 forward compatible or is really better stated that VFP 7 is backward
compatible with VFP 6. Can we say with all certainty that VFP 7 will be
forward compatible with VFP 8? The answer is no....

>As far as I know the VB6 apps will not run in VB7, either unconverted or with the automatic converter. As far as I know the automatic converter converts most of the app and gives you a fix list of things you need to fix.
>

Right, because VB .NET is largely not backward compatible with VB 6. Some code will work, other code - particularly variable declarations may not work. And, if you made use of default properties, you are SOL there too...

>That's what I meant when I used the term "forward compatible."

Do you still feel this way???? < bg >