>>32/64bit - Yes WinDev has this. However, if you must use 32bit ActiveX then the EXE must be compiled as 32bit. You cannot mix 32Bit ActiveX (or 3rd party 32bit controls) into the 64bit EXE.

Agreed, this is true of any dev tool.

>>Your 32bit applications can however access data file larger than 2Gb. No idea how they do it.

Mr Chen has VFPA10.1 in beta also allowing dbf files theoretically into the terabyte range. My only use for this would be for PC data munging because all customer data is in C/S. I look forward to comparing in-memory performance to the old Fox spooling to disk performance that was always impressive.

>>User interfaces – No problem to design any interface you can think of, very modern, slick, lots of tools and code options.

Definitely I agree that its Win32 UI is a VFP downside, though I have no problem with classes that encapsulate functionality.

Just for interest: cross platform UI was a big Fox push in pre-MS days, with .scx and .vcx metadata helping make it easier. More recently (though still last century!) Rick Strahl provided a workable dHTML converter for VFP scx with HTML buttons and visual elements linked via Javascript to the underlying form. More recently again, FoxInCloud presents forms and UI on the web using latest browser UI that can be modernized regularly without touching the underlying scx.

So I find myself musing about using VFP C++ Compiler plus a dynamic HTML5/Angular/Bootstrap/UI-du-jour rendering engine to create native cross-platform apps, just as Dr Dave once envisioned. Passage of the intervening 30 years provides an essentially free cross-platform UI instead of the roll-your-own required back then. You could even write the rendering engine in VFP as FiC has done. So I wonder how feasible it would be to compile into whatever version of C++ is used on whatever OS for a true native app. I suppose it depends how tightly VFP's C++ was bound into Windows, and MS reasonably might take notice if that were attempted.

>>VFP Grid – Does not come close to what is now available - WinDev table controls are way ahead. All WInDev controls are way ahead of VFP controls.

I did see your example of a black box all singing and dancing browse control. Got it.

>>IP protection – sad news … :( I believe that a WinDev application can be reversed. I have not delved into this topic and cannot speak to it categorically and might even be wrong but I have read somewhere that at the end of the day WinDev apps are pseudo or interpretative or semi-compiled or whatever the right term is. The usual solutions were offered which effectively came down to EXE wrappers. I cannot be 100% sure about this topic though so don’t take my word for it.

Having taken a particular interest for some years, IMHO the wrapper protections are irrelevant if the code has to be unpacked as un-obfuscated IL. So this would be an issue if there's strict protection obligation. Just quietly: do look into this, since there are consultants out there earning a fortune conducting security audits that embarrass software vendors, especially in jurisdictions with GDPR obligations.

>>The reason we did not delve into this topic is because at the same time as starting to re-write our apps tools like 2X/Parallels and TSPlus, combined with significant increases in internet bandwidth and low cost servers, became realistic delivery options. We switched all our clients from onsite installs to 2X/Parallels and TSPlus which resulted in serious cost savings on installations and support AND a huge positive feedback from corporate IT departments who were, quite frankly, sick of 3rd party vendors installing their databases and systems on their network servers, having to manage end-users desktop icons, running setup packages, etc. Now we can just give anyone anywhere in the world a login and they have access to our applications via any standard browser either running inside a browser tab or external to the browser mimicking a desktop app!! It was a huge game changer for us. Of course, I realize this might not work for everyone but, thankfully, it did for us.

Got it, though that's not a WinDev advantage it's a Cloud advantage, wouldn't you say?

>>I am not arguing for WinDev. I am arguing that modern development tools bring so much PFT to the table that to ignore them and stick with VFP is at best short-sighted from a business POV.

But has anybody advocated that? Others have made the point that if the business model is T/S or browser, VFP can produce the same HTML5 and Bootstrap or whatever as other tools. If the argument is that WinDev is much better at HTML5 or does it without add-ons, then definitely interested in that.

>>If one argues that VFP can be combined with other tools like C++ or JavaScript or CSS or PHP or whatever then effectively you are saying the same thing – you are still learning new development tools but hanging onto VFP as well.

If you mean VFP C++ Compiler, you don't need to learn C++. The tool converts your work into C++ code that uses standard VC++ MAKE to generate the dll. My interest is (for example) that the x64 Compiler uses VC++10 or greater, whereas VFP is still on V7 that was released in 2002 and still works fine today with millions of apps depending on it, but who knows tomorrow.

>> And it doesn’t when your IDE is no longer competitive from a PFT point of view vs. other tools that your competition has mastered and is using; at that point you're the one still using dBase II and the competition is using VFP9. And it also doesn’t make sense when you start to take a longer term view of your business, imho.

Agreed on the IDE, which is the point made by people like Rick Strahl who have advocated Visual Studio for VFP West Wind projects for many years now. For the rest: I'll take another look at WinDev, though we have paid an absolute fortune over the years looking at various options, even moving to Java at one point and VFP actually has out-survived them all, even options that may carry the same name but would have required multiple total rewrites to stay current.