>Hi VFPers,
>
>A question was asked by a person that did not understand the X# website and what it brings to the party. Robert (Owner) posted a reply and for those who might also not understand, I share it also here:
>
>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 ;-))

There are more parts of vfp coded in vfp prg/vcx: Toolbox, TaskPane, Class Browser, Component Gallery, SourceControl:vcx>>Text, Beautify. Also the Thor tools, which hook into IDE menu: they have a better Code References in vfp source and much more. At least ReportBehavior90, Beautify and Thor-Code References could be seen as good targets, as they should be reused by xSharp. Further parts reusable by just Dotnet-compiling vfp sources ? Something to ask at SWFox, as the speakers there know more on that than me. AFAIK permissive license, and owners of vfp could compile themselves if forbidden to install as compiled with xSharp.

On Speed:
As table handling is very optimized in vfp, I would be satisfied if xSharp is in the same ballpark - if table speed trails vfp by less than 35% including SQL, I'ld jump as only the focus of last tweaking would be changed - more table handling, less code optimizing, slower turnaround also compensated by coding with current tools - handcoding SOAP as vfp does not catch new standards is getting lame ;-)

>The most important part of X# is the compiler, that takes the same source code and produces .Net assemblies.
>The biggest difference of X# is that it is a compiled environment and not an interpreted environment.
>X# tries to figure out at compile time what you want to do with your code and warns you if there are language elements that are ambiguous.
>For example, you can use undeclared variables, but the compiler will warn you about that.
>And for example something like "Customer.LastName" could be a field in the Customer cursor or a LastName property of an (undeclared) Customer variable.

As the xSharp.VO allows

myDbf->lastname := "Funny"
myDbf->age := 111

instead of vfp mandatory replace .. in for tables, danger is much higher there. Guarding reads with m. (m->) is enough, even if looking strange for people coming from other turfs.
>
>For its tools X# uses Visual Studio with its forms editor, menu editors, source code editors etc.
>X# also comes with a runtime library of functions and DBF support and can use all the available components in the .Net framework, for example for reporting (there are many reporting solutions for .Net) and SQL access.

Again - do not invest in replacing ReportBehaviour 80, implement all that is needed to compile the prg/vcx source for ReportBehaviour 90 and make it work and get a speed gain there you can brag about. Should be doable, a good test bed of language covered and a public relations win.
>
>X# itself is more function based than command based (like VFP) but has a pre-processor that helps to translate commands into functions. So you can still write code like you do in VFP.
>For example "SKIP 1" is translated to DbSkip(1) and "SKIP 1 IN Customer" is translated to ("Customer")->DbSkip(1).
>
>We have recently added support for most of the VFP language elements (but we are not completely there yet)
>
>X# and especially its VFP support is not fully ready yet. For example: we are investigating how we can get VFP forms to run in .Net.
>Should we recreate the whole VFP class library or should we convert VFP form definitions to code and use the normal .Net Windows Forms.

Will answer to that topic "over there"...