Foxpro compatibility list

[mainhatten]

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
[/quote}

Definately seconding Matt in that it can be used in programs. Alans argument, since grids were introduced, Browse should not be used in programs insofar false, as browse command was enhanced with "Name" clause, allowing programmatic handling via OOP properties. Use cases are getting scarce, the closer you get to shrink-wrapped apps, but in some use cases where either a Excel spreadsheet could be created or table based solution used, slinging together a few Browses are better than normal forms.
Other use case - similar to using "wait window " against all GUI guidelines is for apps build for limited smart user group on also limited budget

regards

thomas

[mainhatten]

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

"Proper" grids?

Code: Select all

crea cursor t_t (c1 c(20),c2 c(20),n1 I)
insert into t_t values ("Browse", "not really magic", 3)
insert into t_t values ("only dynamic ", "binding of", 2)
insert into t_t values ("some properties ", "to surrounding containers", 2)
browse name oBr_T_T partition 100 Redit
oBr_T_T.Left= 200
? oBr_T_T.Class

Sometimes just a grid is enough for quick peeks - one example before printing oodles, quick-checking the result cursors might be easier than via the print preview.

Full ACK that it is not the common scenario - but "n/a" would be wrong.

regards

thomas

[mainhatten]

This list reflects the status of build 2.08 that will be released this week.

Robert,
I think the following should be switched from n/a to unsupported:

Code: Select all

alter table		&& used often in import tasks
compile			&& multi-line generated code can be executed via execscript AND compile, compile gives benefits
create from		&& table from struc extended
create cursor | TABLE	&& used quite often in my code
create DATABASE		&& in case I need to zip+send DB-enhanced dbf
create TRIGGER ON	&& most of the time probably better done in DD at design time ;-)
create CONNECTION	&& clearly debatable

regards

thomas

[mainhatten]

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

Just thinking through the keyboard: As there are already 3 GUI options, I am hoping for Xamarin/Android/Web[/iOS] as targets when vfp works, the old "browse" command, already cryptic,might need different values/parameters for other GUIs IAC.
I saw in other code samples that {} notation (which is nonexistant in vfp language) is supported. Perhaps translating those few browses used in App code should be transferred to a JSON notation to be Addpropertied to the grid as structure of empty-objects, to be used by a xSharp-function to set correct values, where dynamic setting is overridden.
Such JSON text could be gotten from inserting a special function in the vfp code to read out the Browse and piped into a text file, including lineno(), correct property names and a definable marker text.

no idea how much work configuring parsing of "browse" would be - so there would be an alternative.
There is also the option to persist the grid with all properties in a vcx as a class - take the lines I wrote to Alan and add:

Code: Select all

? oBr_T_T.SaveAsClass("Testvcx", "BrowseDemo", "for xSharp")

regards

thomas

[kevclark64]

Thanks for posting this.

I did a search in the source code of my main VFP program (about 250K lines) and found BROWSE about 10 times. But those are cases where I really should use a grid; so I'd personally have no problem with BROWSE being deprecated.

Are all the items in the list which say "not supported" items which you are planning to support?

[FoxProMatt]

Indeed, BROWSE, is an easy one to live without, or adjust for.

However, DO FORM is a different case, and that one surely cannot be disregarded as easily as BROWSE.

Here is the full DO FORM syntax from Help:
.

Code: Select all

DO FORM FormName | ? [NAME VarName [LINKED]] [WITH cParameterList]

   [TO VarName] [NOREAD] [NOSHOW]

[mainhatten]

Indeed, BROWSE, is an easy one to live without, or adjust for.
However, DO FORM is a different case, and that one surely cannot be disregarded as easily as BROWSE.
Here is the full DO FORM syntax from Help:

Code: Select all

DO FORM FormClassName | ? [NAME FormVarName [LINKED]] [WITH cParameterList]
   [TO ReturnVarName] [NOREAD] [NOSHOW]

Matt,
Yes and No. The "Do Form" syntax is a holdover from GenScrn handling, where the read loop had to be established under DOS and IIRC was issued in one of the generated subfunctions with sys(2015) function names hard to hook from rest of the program.
In GUI read loops became very common, but they had added Name [linked] clause in vfp3 similar to browse name to marry new OOP paradigma with the old syntax - IIRC Do Form will be equivalent to

Code: Select all

private | public FormVarName, ReturnVarName 
FormVarName   = createobject("FormClassName"[,WITH cParameterList])
[FormVarName.SHOW = .f.]
[FormVarName.WindowType = 2]   && Uncertain, would have to read docs on where and when to issue READ... 
&& ReturnVarName will be assigned returnvalue of FormVarName.unload()

My guess is that most code in the wild uses "Do Form", so it should be supported

[mainhatten]

But those are cases where I really should use a grid; so I'd personally have no problem with BROWSE being deprecated.

Kevin,
you are already using a grid - only you did not set all the necessary properties. Having such an option might be useful for checking all kinds of tables on deleted() before packing. As it basicalliy is nothing but a dynamic, uncontained grid, it should be supported - but not with highest priority.

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
  oDT := DataTable{DbAlias()}
  // 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

Voila, the first version of the BROWSE command is implemented in X#.
Hope this is of interest to (some) VFPers and (most) X#ers,

VERY nice for a on-a-moment solution! But as the "smart usage of client disk/resources via local tables/cursors" kept me in vfp for ages when ADO, ADO.NET, Python/Javascript in-memory-cursors returned from their DBAdapters were available in languages sporting nicer other OOP features. I expect (in the end) a solution where skipping in upmost parent of 7 to 12 tables all linked either via "set key" or "set relation" does not cascade into loading/showing 11 such memory tables when on disk everything is already done

[нДраган]

The browse...name and manipulating the automatic grid that gets created in the background could be something applicable now, with just the same trick applied. Whenever there's a browse command, a grid would be created with some default values and that's it. That's what Fox does anyway. Syntactically, not all the clauses are required - the validation, width, saving the setup in foxuser and several other things were rarely used (I know I used them last in FPD). The ability to select fields, including calculated, and to designate scope (browse ... rest, browse ... key) would really help.

[lumberjack]

Hi Thomas,

VERY nice for a on-a-moment solution! But as the "smart usage of client disk/resources via local tables/cursors" kept me in vfp for ages when ADO, ADO.NET, Python/Javascript in-memory-cursors returned from their DBAdapters were available in languages sporting nicer other OOP features. I expect (in the end) a solution where skipping in upmost parent of 7 to 12 tables all linked either via "set key" or "set relation" does not cascade into loading/showing 11 such memory tables when on disk everything is already done

Well seeing Robert posted a working SCAN command with bells and whistles, I leave it to VFP guys to enhance my BROWSE and DbBrowser function to handle more of the bells and whistles...