Foxpro compatibility list

[robert]

Some people have asked for a list of (Visual) FoxPro commands and how they are supported in X#.
I have just added a list to the Help - FAQ menu on this website:
https://www.xsharp.eu/itm-help/foxpro-c ... ility-list
This list reflects the status of build 2.08 that will be released this week.

Robert

[FoxProMatt]

Robert - Thank you for posting this, as promised.

It will be fun to watch the NOT ones fall away in the coming months.

[FoxProMatt]

Robert - what does it mean that commands like BROWSE or DO FORM are marked as “n/a” ??

These are very common FoxPro things to do, even at runtime, so what does it mean n/a instead of “NOT Supported (at this time)”? There will be lots of these particular commands in transported code that will have be dealt with.

Does it mean “this feature will NOT be supported (ever) in X#, so get ready to change any code that you have like this”?

[robert]

Matt,

with n/a I meant "not applicable". These are commands that are part of the VFP IDE afaik, or is EDIT, BROWSE etc also used in production code ?. In that case I'll change them to not supported

Robert

[wriedmann]

Hi Robert,

PMFJI: I have not seen much VFP code, but these commands are very used (like a DBU that is not only integrated in the IDE, but can also be used in the applications - I have seen users open up a command line in their VFP application and typing "browse xxxx".
And I have to admit that sometimes I likes to have that also in my own applications... (I have now a similar functionality as I can drop any DBF file on my running VO applications).
Wolfgang

[alanbourke]

BROWSE is indeed handy, although it is kind of intrinsic to the VFP IDE. It's akin to the functionality that Visual Studio has where you can bring up a quick table inspector based on a connection for convenience. But really, has anyone used BROWSE in deployed software since proper grids appeared in the first version of VFP? If they have they shouldn't IMO.

[lumberjack]

Hi Alan,

BROWSE is indeed handy, although it is kind of intrinsic to the VFP IDE. It's akin to the functionality that Visual Studio has where you can bring up a quick table inspector based on a connection for convenience. But really, has anyone used BROWSE in deployed software since proper grids appeared in the first version of VFP? If they have they shouldn't IMO.

I also feel it would be quite handy, specially during debug to display data quickly.

The nice thing is, one can write a function DbBrowser() and map with #command to it.

Code: Select all

#command BROWSE => DbBrowser()
FUNCTION DbBrowser() AS VOID
  LOCAL oForm AS Form
  LOCAL oGrid AS DataGridView
  LOCAL oDT AS DataTable
  LOCAL row AS DataRow
  LOCAL i AS DWORD
  // Create a table, give it any name you like
  oDT := DataTable{DbAlias()}
  // Make some columns for the table from each column in the DBF
  FOR i := 1 UPTO FCount()
    oDT:Columns:Add( DataColumn{ FIELDNAME(i) } )
  NEXT
  // Now load with data
  DbGotop()
  DO WHILE ! EOF()
    // Create a new row
    row := oDT:NewRow()
    // Put data into the columns in the row
    FOR i := 1 UPTO FCount()
      row[ FIELDNAME(i) ] := AsString(FieldGet(i))
    NEXT
    // Add the row to the table
    oDT:Rows:Add(row)
    // Move to next record
    DbSkip()
  ENDDO
  // Create a form and datagrid to display the DBF
  oForm := Form{}
  oForm:Size := Size{400, 100}
  oForm:Text := "My first BROWSE"
  oGrid := DataGridView{}
  ... // Tie the grid data source to the DataTable
  oGrid:DataSource := oDT
  oGrid:DockStyle := DockStyle.Fill
  oForm:Controls:Add(oGrid)
  oForm:Show()
RETURN

Voila, the first version of the BROWSE command is implemented in X#.

Hope this is of interest to (some) VFPers and (most) X#ers,

[FoxProMatt]

Yes, expect to see these commands used in running apps. Might seem crude by today’s standards, but it was (still is) a real part of writing VFP apps that shouldn’t be ignored. Absent of supporting these there wouldn’t be as full of VFP support/implementation as could be or even needs to be.

“Handy” is not the right way to view these. The are actually used in plenty of cases.

Also, DO FORM, with all it’s supported clauses (WITH and TO), is absolutely required as it is a VERY common way forms are launched and interacted with programmatically. This is certainly in a different category than the older, crude BROWSE command (and its many optional clauses)

[alanbourke]

How many running apps though? Enough to warrant implementing all this ?

Code: Select all

BROWSE [FIELDS FieldList] [FONT cFontName [, nFontSize [, nFontCharSet]]] 
   [STYLE cFontStyle] [FOR lExpression1 [REST]] [FORMAT] 
   [FREEZE FieldName] [KEY eExpression1 [, eExpression2]] [LAST | NOINIT]
   [LOCK nNumberOfFields] [LPARTITION] [NAME ObjectName] [NOAPPEND]
   [NOCAPTIONS] [NODELETE] [NOEDIT | NOMODIFY] [NOLGRID] [NORGRID] 
   [NOLINK] [NOMENU] [NOOPTIMIZE] [NOREFRESH] [NORMAL] [NOWAIT] 
   [PARTITION nColumnNumber [LEDIT] [REDIT]]
   [PREFERENCE PreferenceName] [SAVE] [TIMEOUT nSeconds] 
   [TITLE cTitleText] [VALID [:F] lExpression2 [ERROR cMessageText]]
   [WHEN lExpression3] [WIDTH nFieldWidth] [WINDOW WindowName1]
   [IN [WINDOW] WindowName2 | IN SCREEN] [COLOR SCHEME nSchemeNumber]

[robert]

Alan,
Now all of our source is open, I am sure Matt will write this UDC and the function to implement this
Robert