xsharp.eu

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

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

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