AGPsoftware
This is the question to answer; not the conclusion.
I did mean it as rhethorical question. It is, and the moment you decided to continue your product development with VFPA you bet on that horse instead of VFPX,. VFPX is the VFP communities effort to continue VFP development without changing the VFP core runtime, i.e. it all works on basis of VFP9.
What's more successful remains to be seen, indeed. So I take back my rethorical question.
Still, the point I then made is if Chen stops VFPA development you still are in the same boat as those using the unchanged VFP9 last version. And so the focus should be on moving anyway, have a new mainstay. You're still among the people who want to become the frog that's in the pot starting to boil, you just think you made an evasive move by going to VFPA.
Look at the way things are just now: For example older C++ runtimes still work and are the basis of getting older ActiveX controls to work on current Windows. So older applications needing those older ActiveX also still work. This is also true for the C++ runtime that VFPX and VFPA need. So people worrying about that are having a pointless worry. If all else fails you'll put an application into a VM, and customers needing that will take that path along with you. Sure, that'll become a worry from then onwards and you might lose customers when that step becomes necessary as that's having bad smell. "Why do I need to move software into a VM?" is what they'll ask themselves. No matter if they even understand what a VM is. But if that software is business critical for them, they'll go along. They'll just also look for alternatives.
------------ Cut.
New thought:
You have a big investment in all your VFP codebase. That's a point you always have with anything, if you developed in VB for years, that'S your investment you want to protect. No matter what you use, if you move single tracked you are bound to fail when a track ends, that's always the case, no matter how certain or uncertain a rod map is and how good it looks when a roadmap still exists for the many years, you only can plan ahead for that time. You're now already at a point you stil ride that train without a roadmap ahead.
It was always a lazy and risky business decision to rely on one horse only. And you're already riding a dead horse just with some old support (FoxPro community) and some new support (Chen). You don't change to something main stream because that's so far off that it means a too steep change to make, it would stall all new development as you can't migrate the codebase and enhance it at the same time. Well, that would be easier, if you already would drive on two or three tracks all along. It becomes more and more difficutl the longer you wait.
At some point the worst scenario will be that your valuable codebase you built up all these yearsw doesn't work at all. Maybe not even because Windows doesn't suppoort it, but because people tend to use Macs. So to protect your investment you'll need to go more and more abstruse ways of emulating old Windows versions AND old hardware.
--------------- Cut, next thought
If it is really your concern that Chen also stops development, you didn't drive on the longer roadmap, really. To me the VFPX project and all the features you get from there, which often also work for VFPA are the roadmap of VFP9 that the community chose to build up and will be able to continue longer, because they are more. Even if single persons contributing to VFPX go off that roadmap, it can continue. You trusted Chen more than the VFP community, because, well, you know best because of what. I have looked at some bugfixes and find them unimportant, as I never came across the bug they fixed. I'd say VFPX has more advances than VFPA. But to me the more than 2GB DBFs are not as valuable as they seem to be to you, for example.
So debatable which choice to make. There are different perspectives on whether VFPA is the better continuation than VFPX and if one aspect of VFPA is more important to you, then you made the right move to that roadmap. Now you're woried that stops one day. How peculiar, a deja vu.
If it is the major importance for you to have a sure future roadmap, you have to go with the mainstream. That is an argument that was against VFP even when VFP was within Visual Studio, as it never was a mainstream development tool and programming language. So you bet on the wrong horse in the first place, not just recently. If the sure future roadmap is your concern you would start with and follow the mainstream and that would have meant VB or C++ and nowadays C# or VB.NET. or JAVA all along, or PHP in the web and nowadays maybe Python or ASP.NET for th4e MS enthusiasts. VFP was never on that mainstream road. And at any stage of going of the mainstream you made the step to go back to it harder to overcome. And it will still become harder, the more time you invest and stick with in VFP.
All these arguments are not new, they also were made when VFP9 development stopped. So at least you could have started something in parallel for 15 years now. So once more said, if future safety is your concern then wake up, open your eyes and start on the mainstream platforms, that's the only valid thing to do.
I predict you won't go that step so you have to live with a fear of getting stuck and running to a dead end sooner or later. That's it about that point, there's really no more4 discussion to be lead about it.
Chriss
PS: I'm a bit drastic here. The choice for FoxPro back in the beginning was based on it's stunning performance back then, but even if you was there and witnessed the speed of data acess from local files, if you're honest you'd know it's just a publicity stunt to show the best case performance, it stops being that, once you get to shared access on a LAN and it was clearly that way from way back then until today. So you always decided for FoxPro on the basis it's a good tool for single user applications, it was never good for general purpose data centric application programming which most of the time means client/server and muti user. And you better have an active process on a server for that, becuase - punvch line - local data access is the fastest, so it also is best to not only have data remotely stored (I use remotely also for LAN shares here, anything but local drive files), but also a remote process to which this is local files. And even when having that, you always have the overhead of bringing that to the actual client, you can't prevent having that disadvantage in shared and centralized data storage, and clearly it's not possible to do that best with a serverless solution.
