Foxpro compatibility list

This forum is meant for questions about the Visual FoxPro Language support in X#.

Jeff Stone
Posts: 37
Joined: Fri Jun 07, 2019 4:16 pm

Foxpro compatibility list

Post by Jeff Stone »

Hi Robert,

"- For people that sympathize with the project but can't afford the whole subscription we have added the option to donate money (see the Donate button on the top of this page). To be honest: not many people have used this possibility."

Personally, I can't justify the company spending $825/1,000 for a product that doesn't yet meet our needs. However, I am willing to contribute both some money and testing time. The problem, if I understand the subscription terms correctly, is that unless we pay the full amount, we won't be able to get interim updates which makes testing inefficient at best and possibly extremely frustrating. It might be worthwhile asking for feedback at SW Fox Conference from attendees. My experience has been that VFP/Harbour/HMG members are largely supportive of endeavers such as X#, and the more that are involved, the faster development will be..

Regards,

Jeff

P.S. Is there a way to donate in U.S. dollars and can you add an English translation for "Instellen als een maandelijkse donatie" on the donation page?
User avatar
robert
Posts: 4540
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

Foxpro compatibility list

Post by robert »

Jeff,
Jeff Stone wrote: "- For people that sympathize with the project but can't afford the whole subscription we have added the option to donate money (see the Donate button on the top of this page). To be honest: not many people have used this possibility."

Personally, I can't justify the company spending $825/1,000 for a product that doesn't yet meet our needs. However, I am willing to contribute both some money and testing time. The problem, if I understand the subscription terms correctly, is that unless we pay the full amount, we won't be able to get interim updates which makes testing inefficient at best and possibly extremely frustrating. It might be worthwhile asking for feedback at SW Fox Conference from attendees. My experience has been that VFP/Harbour/HMG members are largely supportive of endeavers such as X#, and the more that are involved, the faster development will be..
I will most certainly ask around at SW Fox.
Btw: almost nobody has pad the full price so far.
At this moment we have a discount of 25 % as well. See https://www.xsharp.eu/store. And for renewals we also give discounts.

Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
mainhatten
Posts: 200
Joined: Wed Oct 09, 2019 6:51 pm

Foxpro compatibility list

Post by mainhatten »

Robert van der Hulst wrote: Adding support for commands like Browse, Edit, Append etc is certainly possible.
But first we need to decide if:
- we will recreate the VFP UI class hierarchy
- port VFP forms and controls to standard .Net controls

And of course there has to be a business case. We need a few people from the VFP community that are willing to invest ...
Hi Robert,

I have definite opinions on that - but before I write too much perhaps unneccessary text, over at LevelExtreme Johan raised a similar point on IDE, runtime, what is run how, including reports, on which my answer was
>Visual FoxPro is an environment that consists of several pieces:
>- An IDE
>- A source code editor
>- A form and menu editor
>- A report editor
>- All of these produce source code that is compiled with the VFP compiler into so called "P-Code"

The percentage is decreasing: in report.frx/frt is some code, but mostly values aka "structure properties", vcx/scx tables in between...

>- This p-code gets interpreted by the Visual FoxPro runtime -
>- and runs with the help of a set of classes and functions and support for DBFs, SQL etc.

Report frx in Reportbehaviour 80 is interpreted directly by the runtime, in Reportbehaviour 90 it is fed to vfp source code included in the install for more OOP options - resulting sometimes in unwanted slowdowns I have heard. As Dotnet runtime speed should be higher, that would be a good way to show people, that the higher turnaround times of Dotnet give "something back" in runtime speed. And NOBODY could claim you rigged the benchmarks if you used sources included in vfp itself - selected a favourable arena ok, but used code vfp originators thought was good enough to include.

Much better than selective raisin picking to find areas where new tool obliterates old champion, but never used in reality ;-))
Are you already aware that all reporting enhancements to give better control as well as to "OOPsize" reporting (Reportbehavior 90), debuing in vfp9, are not inside the runtime as was previous reporting, but totally written in vfp source code and that vfp source can be found on https://github.com/VFPX/ReportingApps ?

regards
Thomas
Post Reply