Some "conclusions" from meeting FoxPro customers at SW Fox

[robert]

We have just returned from SW Fox and have spoken with many VFP developers at that conference. Before we went there we had some questions and we discussed these with the people there. We have returned with some answers and with some questions that are still open.

Below is a summary of some of the conclusions (in the text below cursor = workarea)

- We will add support for SQL based cursors . A function such as SQLEXEC() will return a temporary, disconnected (in memory) cursor based on the DBFVFP driver and with the same data types that this driver supports. You can create indexes on this cursor and use the normal operations on this cursor that you can also use on other cursors. Updates to this cursor will not be written automatically. The developer must issue UPDATE, DELETE or INSERT statements to update the data in the original database.

- We will extend the column types with Unicode character and Unicode memo fields, so Unicode results from a SQL query will not have to be converted to Ansi

- We will also add support for the embedded SQL in the language. This will be limited to simple selects (no joins) in the first release.

- We will add a function to the runtime that allows you to take a cursor and use this as datasource for .Net forms, grids (WInfoms and WPF). There will be 2 variations: a) with direct updates and b) with batch updates

- We will add IEnum() support to the cursors so you can use LINQ queries on a cursor

- We will create a tool that converts VFP projects to .Net solutions / projects, including VCXs, Forms, Menus and reports. The forms will be converted to standard Windows Forms forms. This means that event handlers will need some "post processing" because the event handling in .Net differs from VFP. Almost everybody we spoke with prefers this over a solution where we would create a VFP compatible class hierarchy on top of Windows forms, with a new VFP Compatible form editor. The advantage of using "normal" windows forms is that you can directly use the standard windows forms editor and will have no problems using .Net control libraries from 3rd party vendors such as DevExpress, Telerik and Infragistics.

- For the reports we have made no final decision yet. Most likely our converter tool will read the report definitions from VFP and convert these to an (intermediate) XML format. We may add support for this XML format to our own report writer ReportPro, but we also got some feedback from VFP developers that they would not mind switching to other .Net report writers. In that case we (or the 3rd party) could write a XSL transformation from the XML format for reports to the other tools.

- W.r.t. the development language we have heard from VFP developers that we should not try to recreate language constructs from VFP that violate normal programming principles. For example there are functions inside VFP that accept a variable name and will create a new variable outside of their own execution context (in the context of the code that calls this function). This is NOT normal in other programming languages. Other languages expect that the variable is declared before the function call and passed as REF or OUT variables to allow them to be changed outside of their own context.

Robert

[wriedmann]

Hi Robert,

thank you very much for this information - interesting also for non-VFP users like me.
Embedded SQL in the language and SQL based cursors sound interesting, and maybe could be interesting also for other people not using the VFP dialect.
Wolfgang

[FoxProMatt]

Robert - these are all great points.

Relative to :
.

A function such as SQLEXEC() will return a temporary, readonly (in memory) cursor...

I have added some more comments about SqlExec() to a previous thread on the same topic:

https://www.xsharp.eu/forum/private-vfp ... rsor#11550

[robert]

Matt,
This is what I meant. A disconnected cursor, so updates will not be sent to the server automatically.

Robert