<snip>
>>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.



I am thinking purely in terms of visual compatibility and current code execution under Vista in order that current VFP9 apps can look and feel like Vista apps. This would cover all visual elements, menus, dialog boxes, form controls, toolbars, etc. In addition, some assurance that service packs and upgrades would be made available just in case future Vista service packs or upgrades negatively affect VFP9 apps.

This would ensure that VFP applications, used by millions of end-users, would not look dated and would run correctly under Vista. This in turn would help MS because VFP shops, like mine, would contribute towards migrating end-users to the Vista o/s. Is this not a desirable (and achievable) goal for MS? As an added incentive let such developments and assurances only apply to VFP 9 thereby forcing developers to at least upgrade to version 9.

I am not talking about any development that would extend VFP in other ways such as PDA development, running under .Net, or other functionality such as file size limitations and so forth. For those objectives I think we should consider any of the many other alternatives already available. Personally, I like WinDev but there are many options already out there, not least of which the .Net development tools.


This message is blogvertising free.