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?
Foxpro compatibility list
Foxpro compatibility list
Jeff,
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
I will most certainly ask around at SW Fox.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..
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
The Netherlands
robert@xsharp.eu
-
- Posts: 200
- Joined: Wed Oct 09, 2019 6:51 pm
Foxpro compatibility list
Hi Robert,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 ...
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
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 ?>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 )
regards
Thomas