>I agree with you, Tracy, and Weldon. What amazes me is the attitude of "it will achieve nothing". Apathy or realism or something else ...?
>
>But even if it does not achieve VFP10, which imo I don't think is necessarily the right goal (see below), it does achieve something. It will make people, and MS, aware of the VFP community and, more importantly, of the hundreds of thousands (millions?) of end-users who use VFP applications.
>
>Just 2300+ developers account for over 550,000+ workstations running VFP apps. Extrapolate those numbers to the total VFP developer community. Someone said the pool of VFP developers numbers in the tens of thousands. Can you imagine what this translates into for the number of actual end-users using VFP applications?
>
>Hundreds of thousands of end-users, possibly many millions of end-users, are going to be affected in one way or another if those VFP apps cannot run and look correctly in current operating system versions including Vista.
>
>In respect of what I would like to achieve with this effort - I don't need VFP10. What other features does one really need, as opposed to want? VFP9 is so feature rich I personally don't even use it all now. For me, and I suspect for many here, I would be happy if VFP can be made to work correctly, in all respects, under current Windows operating systems including Vista. This would include support for all visual elements as well as code execution. More importantly, this should include future service packs to attend to any compatibility issues that may arise with future Vista service packs and upgrades. If one achieves this then VFP apps will look modern and work correctly under MS's latest operating system.

Very sensible arguments here. I remember Yag having promissed Vista compatibility, starting with Sedna. But I guess there's compatibility and compatibility. And you're probably foreseeing new elements in Vista that won't gonna be supported by VFP9+Sedna.

Is this an appropriate example? The getdir function supports a flag 64 that will invoke a Windows variation of a dialog box that can be used to select a directory. Suppose in Vista a new variation is introduced. That new variation cannot be invoked in VFP for as long a new flag value cannot be set. (Unless of course the programmer uses the direct API call.) Are you thinking along such a line?

Don't we need 'other features'? What comes to mind is the possibility to develop for a PDA. Other tools can be used, but why not declare a subset of the VFP language as valid for that purpose and publish a separate builder/compiler? Or we might use ETec's stuff for that.



>Surely this is an achievable goal and would extend the life of all VFP apps well into the future. This goal would also directly benefit MS because it will contribute towards upgrading end-users to Vista if those end-users are being sold and pushed Vista compatible versions of those VFP applications. Isn't that worth signing for?
>
>
>
>This message is blogvert free :)