>Hi Jos,
>
>Certainly I appreciate civil discussions about experience from people who knew and used finer VFP features, and now use some other tool.
>
>From my VFP POV: I have four basic interests looking forward: hundreds of thousands of lines of existing code, mostly taking advantage of unusual VFP in-line data processing; 64 bit; evolving user interfaces; and protection of intellectual property.
>
>In my case, 100% of main customer base uses Wiindows, usually with more than one HD monitor. This allows consideration of Windows desktop apps that we had moved away from in the late 1990s when we moved everything to the browser. It's possible somebody might want to run one of the apps on a tablet which would be more of an issue for a Windows app... if not for TS that (again) 100% of main customer base already maintains. Meanwhile the desktop app allows multiple communicating forms/windows with split-second refresh that was far more difficult or even blocked in prevalent browsers.
>
>So:
>
>- VFPA and VFP C++ compiler offer 64bit, allowing compilation up to the very latest VC++14 that should enjoy MS support until everybody here is long-retired.
>
>- Evolving user interfaces remain acceptable if you use VFP's Desktop property... apart from half-height title bars that are painted in pre-Metro style, and inability to put buttons in the titlebar (which I know breaks Windows design standards but is used productively by lots of other apps). One solution is to paint your own titlebar, which is the path we took based on an VFPX model. But there's no doubt that the UI is aging as is the IDE for those who still use the native VFP version.
>
>- Moving to 64-bit ends use of existing flls and ActiveX, which is where inbuilt functions for encryption/compression you describe, certainly would be appreciated. However, the underlying code is readily available and we found out how to roll our own in VFP C++ Compiler where it' now encapsulated.
>
>The VFP grid has some nice features but it is aging and I agree it takes work to twist schedulers or treeviews out of it. Having said that, years ago I saw VFP apps making very nice use of scheduler ActiveX controls.
>
>IP protection: a lot of developers say they don't need it... until they discover their work being used or even sold by others without attribution or compensation, or fail a Security Audit because of insecure database credentials or similar. VFP C++ Compiler offers terrific IP protection, moving most functionality into a C++ dll that cannot be decompiled back to source. I'd be interested to know more about WinDev protection.
>
>For the rest: over the years I've remqained a fan of the unpopular Remote View and make extensive use of VFP's direct data munging allowing incredible performance for certain processing tasks covered by contracts that can make you liable for an entire country license if your laxness leads to unauthorized use in unlicensed jurisdictions.
>
>Any insights you can offer are greatly appreciated! - J


John,

As I said to Denis, and as I am sure you know already, such decisions are hard. They must be made using a cost/benefit analysis. The best I can give you is how we thought about it with our apps which have evolved over 30+ years and also contain hundreds of thousands of lines of code. For a little background; our apps do financial analysis and reporting/charting of financial/investment data including plotting real-time graphics and updating reports/tables with real-time pricing data.

Let me start by saying that I do not frame the question of moving to a new development tool as an all-or-nothing decision. It is not, in my view, a case of dropping the old and moving only to the new.

Things we considered:

There were many things to consider some of which were:

1) Where do we want to be 5 years from now or 10 years from now.
2) How does our product look like vs. the competition’s slick new interfaces.
3) How fast can we modify/enhance our applications vs. the competition.
4) How is our client base changing. Older users retire and new users come into the game.
5) What technology do the new users prefer. Older preferred desktop, newer prefer smartphone or web.
6) How much resources were we spending on 3rd party tools which themselves need learning curves, maintenance, etc.
7) How many 3rd party tools are now EOL; PHDbase, Dynazip, Molebox, Thinstall, GraphicsServer, CommandBars, Foxweb, etc.
8) What functionality were we endlessly hacking and cobbling together from other tools and DLLs etc.
9) What functionality could we not even create at all.
10) What did we say when a client asked about the tech being used.
11) How did our tech look to potential buyers of our business, how did that frame us in their minds.
12) I’m sure there were more considerations but this comes to mind at this moment.

What’s the Deal with New Development Tools:

To my mind there are at least three core things that a new development tool can give you;

1) Productivity
2) Functionality
3) Technology

Productivity:

I have given an example of productivity in another post about browsing a table. This type of built-in, out-of-the-box leap in productivity comes in every aspect of a new development tool. New development tools allow developers to be more productive, productivity is time, and time is money.

Functionality:

New development tools come out-of-the-box with far greater set of functionality; tools, controls, super-controls (controls that contain multiple controls), and so forth. Functionality allows you to quickly and easily expand the functionality off your applications with new controls and tools and access things that might not be possible in older development tools or only in a cumbersome way employing yet more 3rd party tools.

Technology:

New development tools obviously have a lot of new tech including 32/64 bit, larger than 2Gb file limit even in 32bit apps, built in database encryption, database replication, application telemetry, mobile and tablet platforms, web solutions, SAAS, social media tools, etc. etc.

Re-Writing Issues:

If re-writing apps is always a failure then why did we rewrite our apps from MS Basic (DOS) to dBase II (DOS) to Clipper (DOS) to FoxBase 2.6 (Windows) to VFP3 (Windows) to VFP9 (Windows) to WinDev (Windows/Web/Tablet/Mobile)? Because each new language gave us additional PFT (productivity, functionality, technology). And each move was successful. And each move put us ahead of the competition in those 3 key areas. We out-gunned much larger competitors by using cutting edge technology which we were willing to expend the resources on for rewrites.

Now the problem is that upgrading development tools takes resources, time, energy, money and when we looked at .Net and other tools they required a far larger learning curve, at least for us as VFP’ers, than WinDev. WinDev works and looks like VFP in syntax and project development. When we saw the syntax we realized we were effectively reading xBase code. This is the primary reason we choose WinDev, not because it is better than, say, .Net or Python or whatever (I wouldn’t know how to measure what constitutes “better” anyway) but because coming from VFP it is immediately recognizable and the development process is the same.

As an aside – we originally looked at WinDev around about 2005/2006. We even bought the then current versions. But we still felt we could stick with VFP and we pushed the envelope of that product to the best of our abilities (which are far short off a Sergey or the other UT / VFP gurus including yourself). Even so, VFP kept us ahead of our competitors not least of which because they also choose poorly; they chose MS Access or Visual Basic or Delphi or Silverlight – LOL :)

So, when we thought about the points at the beginning of this post and looked around and found a tool that had so much PFT and looked and felt like VFP that we planned a migration. The idea was NOT to drop our VFP apps but rather to focus on a new version of our applications which we could re-design and re-imagine in view of mistakes made and lessons learned and new technologies available etc. And then we began to build the new version in WinDev while maintaining and only occasionally enhancing the VFP apps. All our efforts went into the new version.

How long did it take? Our VFP apps were built over years, somewhere from 2000 to 2014/15. Of course, this was an organic development process, enhancing and adding as time went on and clients gave feedback etc. But it had become a fairly stable product with only minimal enhancements from time to time. We re-wrote it all in 1 year with WinDev which is mainly because we didn’t have to figure it all out again but also because the tool does a lot for us which we previously had to code. We knew what to do and then basically converted VFP processes to WinDev processes. Now this last paragraph might be much harder to achieve if moving to a non-VFP-similar development tool. There the learning curve might be harder and take more time to become proficient.

Business is Business:

We consider ourselves neither expert in VFP nor WinDev but we have managed to achieve the goal of keeping and maintaining our VFP apps for those clients who do not want the effort of learning anything new and at the same time have a modern version in a modern development tool with new bells and whistles and with much more PFT to help us as a business. Again, I repeat, it is not an all-or-nothing approach. It is not drop VFP and only use the new re-write. It is a business process of planning where will we be X years from now with this new development tool vs. competitors, and the state of technology, and new platforms that are available, etc. And how much can new PFT tools save us in costs and increase our revenues or maintain our revenues in the face of competitors also using newer and more powerful development tools.

Specific points you mention:

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.

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

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

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.

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

I must repeat, I am not sure if WinDev apps can be reversed - I simply dont know. I could find out though ...

Concluding thoughts:

We do not consider ourselves experts in VFP or WinDev. There are experts in WinDev out there, in the US, Germany France, elsewhere. But we are not one of them. We are amateurs with access to powerful tools that we most certainly are not using optimally. We tend to get it working and move on whereas others might delve far deeper into the tool and optimize far better than we do. But like I have said, we are business people first, developers second. We need to get solutions out the door quickly and that impress clients. No one ever paid me for perfect code or for the speed of our million repetition FOR … NEXT loops.

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.

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. That makes sense until it doesn’t. 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.

I hope I have covered your questions and that the insights, such as they are, were worth wasting your time on reading them … LOL :)