FoxPro function list updated

[robert]

We have updated the "compatibility" list for FoxPro with a list of functions.
See here: https://www.xsharp.eu/itm-help/foxpro-c ... ility-list

We differentiate between:
1) Functions that are already completely supported
2) Functions that are supported differently (with more or less parameters)
3) Functions that are not supported yet
4) Functions that will not be supported

In the last category are functions such as:
- Functions that have to do with the FoxPro IDE
- Functions that have to do with the FoxPro UI system (Window and Menu related)
- Functions that have to do with DDE
- Functions that have to do with the way FoxPro implements COM
- Functions related to the FoxPro way of error handling (ON Error ....)

If you think we made a mistake in this list and a function that you must have is not included, then please report that here. Most likely there is an alternative in .Net.
Some of the functions are UI related, such as MessageBox(), GetFont() and GetPict().
We will implement these on top of the Windows Forms classes.

[FoxProMatt]

Robert - thank you for working on this list.

I think it would be easier to digest these if you separated "Database and Workarea commands" and the "Other Commands" into "NOT supported", "n/a" and "supported" groups similar to what you did on the "Functions" list. (See screenshots below).

I also suggest "Not Implemented" instead of "NOT supported". I think this phrase better indicates that it's in-process just not there yet.

Something like this:

2019-12-09_16-37-06.png (55.37 KiB) Viewed 695 times

And this:

2019-12-09_16-45-23.png (117.74 KiB) Viewed 695 times

[FoxProMatt]

Johan posted a link to this info on Leafe email list, and I'm posting one reply from that list to show feedback from another FoxPro user:
.

The one that caught my eye is SCATTER/GATHER not (yet) supported. I use those commands in everything I do in my VFP apps, especially in single record Add/Edit screens. My objects have a controlsource like "Thisform.oRecord.MyField" which gets populated via something like:

Code: Select all

DO FORM frmEditRecord NAME loFrm NOSHOW
SELECT MyTable
SCATTER MEMO NAME loFrm.oRecord
loFrm.Show()

IF loFrm.lSaveChanges THEN
    thisform.obiz.UpdateRecord(loFrm.oRecord)
ENDIF

IF VARTYPE(loFrm) = "O" THEN
    loFrm.release()
ENDIF 

[kevclark64]

I think the Foxpro toolkit for .NET has been mentioned on this forum before. Looking at that versus the list of currently unsupported Foxpro functions, I'd guess that at least 50 of the functions are supported in the toolkit. The toolkit is public domain so it might be a good resource for getting those functions into X#.

[FoxProMatt]

Foxpro toolkit for .NET

https://github.com/mattslay/Visual-FoxP ... t-for-.NET

[robert]

Kevin, Matt,
We are aware of this toolkit. For the upcoming build we have focused on getting the FoxPro support for Alias.FieldName to work (and to make sure that we can distinguish between Variable.Property and Alias.FieldName) and some issues w.r.t. passing values by reference.
This build should be released to the subscribers in a few days.

After that I expect that we can added support to several of the commands that we don't support yet (SCATTER and GATHER) for example and the support code for these commands.
We'll also work on the various runtime functions and will try to add support for cursors based on SQL statements.
And we continue our work on the Form converter.

Embedded SQL is a different thing. We will discuss that in our meeting in Athens in the 2nd week of January.

Robert

[FoxProMatt]

Robert - what is "... our meeting in Athens in the 2nd week of January."

[FoxProMatt]

Robert - when it comes to the Runtime Functions... I really wish there was a way the community could be involved, if not responsible, for bringing in this layer of X#.VFP.

If you could set a best-practices example of how to implement a missing Function, and then people in the X#.VFP community could write the code for it and submit a pull request to implement it. Make them do some of the work instead of belly-aching at you about missing functions! One thing that does make this less than optimal is that while you may know which functions can just be wrappers around existing X# stuff, whereas someone not familiar with X# will come in and do a full implementation on a function from scratch, and miss that opportunity to take advantage of existing X# pieces.

Regardless, if VFP community got involved in any real way, it could be very beneficial long term and it would allow this X#.VFP to progress a little more rapidly as it would allow the X# Team to focus on much more important low level things like the elephants in the room (Native FoxPro SQL support, SqlExec(), Scatter/Gather, Reports, Form conversion).

[Chris]

Robert - what is "... our meeting in Athens in the 2nd week of January."

It's customary, every year about that time of the year (and often a couple other times per year as well) for our team (or at least as many of us can make it) to meet in person for some drin...errr I mean for some productive discussions, hand on work on various X# aspects etc. Actually (seriously) during one of those meetings we managed to get for the first time the complete VO SDK to compile and work properly in X#, which was a major milestone.

Here's a pic from our first meeting in Athens in 2016 (wow, it really feels like it was a lot longer ago, so many things happened since then!): https://www.xsharp.eu/articles/blog/bes ... s-for-2016

[wriedmann]

Hi Matt,

... our meeting in Athens in the 2nd week of January

given the fact that 2 of the 4 team members are Greek, this makes absolutely sense. And in January the weather in Greece is normally better than in the Netherlands and in France - so this makes such a meeting more interesting.

Wolfgang