>>
If VFP is out of VS then there will be a lot of arguments about VFP not being a "real developer's tool" like VB + SQL-Server
<<

Those arguments are already widespread. Case and point: the editor of VBPJ said in as many words that VFP is a JV language since it is not part of the CLR. A rediculous statement withoout merit. Nonetheless, as long as VFP remains in the box, the questions about why VFP is in the box will remain. To add further fuel to the argument, what does it say when 3rd party languages like Cobol will target the CLR - and yet MS's own language - which ships in the box - VFP that is - will not target the CLR. It makes no sense. Therefore, it should be taken out of the box.

Once out of the box, the issue no longer exists. Dot Net applications are targeted to a specific class of app that VFP is not. Again, this is why VFP should not remain in the box. Outside of the box, and with MS's support - VFP has a legit shot in the Desktop App. Market - which IMO - will be viable for some time to come...

>
Of course a lot of the desktop, small business market doesn't care what the app is written in.
>

This statement is not as true as it used to be....


< jvp >