Poll #4: What (proposed) successors of FoxPro have you tried, plan to use/learn about?

[Chris Miller]

I'm just interested. Also see other polls about past, current, planned versions, and other languages.

 

[Joe Crescenzi]

I've considered every option, but thus far I don't see anyone standing out as the winner because I don't want to start from scratch, re-building every form, class, and report.

For years, I hoped Alaska would deliver their promised Polar Fox, which they claimed would have a direct path for FoxPro, but to this day, nothing.

Some of the web based products simply sit on top of FoxPro runtimes, which is a decent option, but not exactly what I'm looking for. I still want to deliver desktop apps too.

Another problem is that some of the other platforms that claim to have FoxPro as a language option don't seem to have support for FRX report files. I don't want to redesign countless reports.

What I want is something that can use or convert existing files like PRG, SCX, VCX, and FRX files and that fully supports SQL passthrough and that can at the very least continue work with future versions of Windows, but ideally also support MacOS or other platforms. Web support would be a major plus, but not if it makes the code no longer work on the desktop.

 

[Scott24x7]

I haven't found anything that is really reasonable.

 

[D-Ward]

Have recently looks at both Servoy and Alaska XBase, and like Joe above got excited about Polar Fox as it seemed to be exactly what I was looking/hoping for, but not sure if it is going to happen or not.

Had a very quick play with FoxInCloud about a year ago, but struggled as was either beyond me or I just didn't devote enough time to it. Am mainly doing desktop apps, but would be a good addition to be Web and mobile apps as well.

 

[ggreen61]

None. I only support several applications in VFP for limited customer base. No point trying to move to a different platform.

 

[mmerlinn]

None for several reasons.

1) I only write and maintain FPM 2.6 for in house applications
2) None of those will work on any of the MACs I use.
3) I am too old to waste time learning something that I will never live long enough to be proficient with.

 

[GTGeek88]

Give up on Alaska. That's a joke!
Servoy: They reach their hands DEEP into your pockets.
Lianja: Wish I had a month to spend on it. I feel like it has great potential. I wish they would do updated training videos.
etecnologia: Never heard of it.
baiyujia VFP C++ Compiler: Did not realize this was available.
baiyujia VFPA: Very interesting. Not sure about how well the changes are tested. Kind of afraid to use it in production.
FoxInCloud: Well, maybe. Haven't tried it.
Guineu: Not a VFP replacement. Not updated in years.

Other stuff:
Alpha Anywhere: Powerful, but these very smart guys are trying to make their product too much "no code." What this means, since they have tons of capabilities, is an interface - because you're so often just setting properties - that is very complex and deep. This makes it hard
ThinFinity: With a few lines of code, run your desktop app on the web. I have used this. I actually am using it at the moment. But as good as it is, it does have a few problems. I ran into problems running an app in my iPad Mini and using tablets was an important use case for this project. And, unfortunately, I've seen problems even in a browser under Windows on a laptop. In many ways, it works quite well, but I'm not convinced that the problems are rare enough for me to continue using it. There are other products that perform a similar task. Maybe they are better.
Xojo (formerly RealBasic): It certainly has possibilities, but their development progress has always seemed slow to me. But you can use the same codebase for desktop and web, as I understand it. There is a free version for you to use to try it out and determine if it fits the bill. There are a good number of libraries that extend it.

 

[Chris Miller]

Guineu: Not a VFP replacement. Not updated in years.

True, I just know Christof uses it himself. The idea behind it is to stay VFP and have a replacement runtime once MS may decide against compatibility with the vfp9r.dll and - as a more realistic danger - the msvcr71.dll C++ runtime. I guess C++ 7.1 is already older than VFP9 and also deprecated. Not that C++ is deprecated, but that version of C++ has had end of support and at some point MS might decide to only support runtimes of languages within their support life cycle as a step of securing Windows against hacks of such old runtimes. You'll then still be able to run in some VM with older Windows versions, so far even with Win11, so it's not a big threat, but having a runtime that can upgrade to the latest .NET framework you have the best guárantee to run your VFP built byte code even when it might become a problem to run VFP executable with their native runtime.

Besides that Christof has advanced the language and added features by using SYS() functions with not used numbers - which actually is a first step of VFP language improvement as far as I know, it's the way VFP functions are first implemented and then they get an alias name, there are examples which have both, like ID() and SYS(0),

So while it's not replacing VFP, it's prolonging its life, to him at least.

 

[Joe Crescenzi]

True, I just know Christof uses it himnself. The idea behind it is to stay VFP and have a replacement runtime once MS may decide against compatibility with the vfp9r.dll and - as a more realistic danger - the msvcr71.dll C++ runtime. I guess C++ 7.1 is already older than VFP9 and also deprecated. Not that C++ is deptrecated, but that version of C++ has had end of support and at some point MS might decide to only support runtimes of languages within their support life cycle asa a step of securing Windows against hacks of such old runtimes. You'll then still be able to run in some VM with older Windows versions, so far even with Win11, so it's not a big threat, but having a runtime that can upgrade to the latest .NET framework you have the best guárantee to run your VFP built byte code even when it might become a problem to run VFP executable with their native runtime.

Besides that Christof has advanced the langauge and added features by using SYS() functions with not used numbers - which actually is a first step of VFP language improvement as far as I know, it's the way VFP functions are first implemented and then they get an alias name, there are examples which have both, like ID() and SYS(0),

So while it's not replacing VFP, it's prolonging its life, to him at least.

I think VFPA is using newer C++ Runtimes too, and it's basically identical to the last official release, with some bug fixes. The developer also got rid of the 2GB file limit, but that's not a concern for me.

I still won't use it in production, if at some point Microsoft discontinues support for Windows 11 and the old C++ runtimes, it's good to know there's a newer build that works with newer runtimes. For that reason alone, I support the developer with donations from time to time.

 

[Chris Miller]

You could say VFPA has gone the more straight forward path of making VFP work with newer C++ runtimes. Anyway, the idea to base a VFP runtime on the .NET framework enables all kinds of new options as you dive into the .NET world, that way. One consequence of that is that Guioneu also works on Macs. As long as MS also ports the .NET Framework to it. Remember Mono? After MS then decided to go in themselves with Silverlight and .NET Core it was even more open and officially bringin VFP byte code to work on thse platforms, too. But is it continuing? I know by now you can also run MSSQL Server on Linux, but is the .NET Framework support for other platforms extended?

 

[Joe Crescenzi]

You could say VFPA has gone the more straight forward path of making VFP work with newer C++ runtimes. Anyway, the idea to base a VFP runtime on the .NET framework enables all kinds of new options as you dive into the .NET world, that way. One consequence of that is that Guioneu also works on Macs. As long as MS also ports the .NET Framework to it. Remember Mono? After MS then decided to go in themselves with Silverlight and .NET Core it was even more open and officially bringin VFP byte code to work on thse platforms, too. But is it continuing? I know by now you can also run MSSQL Server on Linux, but is the .NET Framework support for other platforms extended?

Microsoft has frustrated me for decades as they keep pushing developers to entirely different paradigms, then drop support a few years later.

I jumped on COM and .ASP as soon as it came out, only to abandon boatloads of code when ASP.NET / ASPX replaced it. Then I focused on ASPX with VB. I assumed VB would always be supported because Microsoft was literally founded by providing Basic to major companies like Apple and IBM. Then it became apparent that their support was moving towards C# and for some reason F# in their cross platform strategies.

C# was an easy choice because I knew C, but then they blew things up again with countless "Flavors" of ASPX and .Net. The original model of .aspx, .ascx, .master, etc., started dropping out of the default Visual Studio installer in favor of MVC, Core, and other models. Visual Studio got bloated with useless starter templates that make no sense, but don't get me started with Visual Studio. I can write a book about what's wrong with it.

This is just the tip of the iceberg. Microsoft has renamed and depreciated more products than I can count over the years. OneDrive was SkyDrive when it was part of Office Live Workspace which is now Microsoft 365, which used to be called Office 365, which used to be just Office.

Microsoft 365 includes Outlook, but then there's also a service called Outlook, and a mail program called Outlook that is built into Windows but it's definitely not the REAL Outlook that you only get with Microsoft 365.

OneNote is built-in to Windows, but it's also part of Microsoft 365, but that's actually a different program too. Terminal Services is now RDS, Azure AD is now Entra... I can go on, but that's another book.

Speaking of Remote Desktops, there are multiple versions of the Remote Desktop program, some built-in to Windows, others from the Windows and Apple App Stores. They don't look or run alike, but all had the same names... until this little gem popped up on my app:



Sure. That makes sense, the program people will look for to run their Remote Desktop will now be called the Windows App. Brilliant.