Fox Pro

FoxPro, or VisualFoxPro, is an object-oriented ISAM DBMS currently owned by, but not originating from Microsoft. It's a derivation of early ExBase.

from Microsoft

Well, not really. From David Fulton's "Fox Software" originally based in Ohio. Microsoft bought them when they were clearly kicking everyone else's butt in the desktop DBMS space.

MS purchased FoxPro for two purposes it appears: First, as a hedge in case MS-Access didn't fly in the market (it was in production at the time), and second, to obtain the "Rushmore" performance enhancement technology, which was used in other MS products.

It is first a language (a dialect of xBase), second a DBMS. It doesn't get down on the hardware, but boy, can it sling data.

The "object-oriented" overlay has really done little to enhance the language or the engine.

Yes, the last two versions from FoxSoftware? before MicroSoft bought them (2.0 & 2.5) added the table-based storage of screens and reports as well as a subset of SQL (nicely enhanced with some language integration features).

This stuff was deleted for some reason. I put it back.

I think FoxPro blew an opportunity to maximize the use of DataDictionary(s) and ControlTables? in place of objects for GUI's, reports, etc. Version 2.6 actually used tables to store screen and report setups (although it was not documented in the formal manuals and appeared a little rushed); but they did not continue with that tradition when they OO'd it for version 3 and on. It could have been something unique, instead becoming a me-too product.

I thought I spotted some tabled GUI elements in VisualFoxPro 5 also.

The above statement is incorrect. The Visual versions still store screens, report, visual class libraries, project and intellisense information in Fox tables. They are 'free' tables not tables that belong to a database container. Someone may have deleted the statement because it is incorrect.

It can tend to polarize conversations. ("It's a toy." - "No, it's not." - "Is too." - "Is not.")

As a language xBase sucked. In that sense it *was* a toy. However, its strength was integrating tables into the language and making tables easy to create, browse, and program. If you use tables to organize your applications, then the weakness of the language mattered less. However, it generally lacked views and other virtual tools of relational theory. But that also made it fast in the age of 386's. They later added SQL support, I would note.

I fed my family for almost 10 years with this toy. Not bad for a "hopelessly inadequate" language/DBMS as some of its critics have termed it. Its ability to interactively debug a concept before committing to an approach was something I valued highly.

For an (admittedly poor) example of FoxPro 2.5 (for MsDos) code, see http://josako.freeservers.com/tech/FoxPro/ - JayOsako

RPN Calculator Example (originally posted on usenet)

Here is a quicky FoxPro-based Reverse Polish calculator script that uses a table to define the buttons and their action. Given a choice, I would probably have used parameters to pass around more record references instead of leaving it to global context (one of XBase's S.E. weaknesses) For example, passing around a PHP-style associative array for references to the looked-up Keys (a table) record.

It only does integers, and the validation is rather skimpy. Also, I don't really need the "Op" column since the operations happen to fit the display characters. However, I assumed that they could be different, such as displaying "X" for multiplication instead of an asterisk.

(Shayne originally requested floating point. I skipped that this time around and just did integers because it would have added more validation and formatting nitty gritty that I thought perhaps distracted from structural issues. I hope this is not a problem. Also, some news-readers may mangle the formatting and indentation. If so, I apologize. Try a Courier font if you have problems. Tabs also somehow got mixed in, and you know what they do to formatting.)

Regarding this line here:

  calc = operand1 &theOp operand2

The single ampersand implies a syntactical substitution. Thus, if theOp is "+", then this gets executed:

  calc = operand1 + operand2

Note that I still don't consider this example very representative of applications that I encounter. But, I thought it might be interesting to see what and how people think of it.

 (begin program code)

 ***** Procedure calculator

 set compatible foxplus
 set readborder on
 set deleted on
 set exact on
 set confirm on
 set safety off

 close data
 select a
 use keys.dbf alias keys
 select b
 use stack.dbf alias stack
 zap

 butno = 0
 dusplay = ""      && number display ("display" is a reserved word)

 *---define GUI window and event handling
 IF NOT WEXIST("form1")
  DEFINE WINDOW form1 ;
   AT 8, 40 ;
   SIZE 14,28 ;
   TITLE "Calc" ;
   FONT "Courier New", 10 ;
   FLOAT ;
   CLOSE ;
   MINIMIZE ;
   SYSTEM ;
   COLOR RGB(,,,192,192,192)
 ENDIF

 activate window form1

 && displays buttons generated from table

 select keys
 scan
   temp = charcode
   tempparm = '"' + charcode + '"'
   @ Yloc, Xloc get butno ;
     picture "@*HN " + temp valid butpress(&tempparm)
 endscan

 activate window form1
 read cycle modal

 return
 *--------------------
 procedure butpress
 parameter theKey
  select keys
  locate for upper(keys->charcode) = upper(thekey)
  do case
  case keys->optype = 'K'     && digit constants
    dusplay = dusplay + charcode
  case keys->optype = 'C'     && commands
    do commands 
  case keys->optype = 'P'     && math operation
    do operations with keys->op
  endcase
  &&----display update
  @ 1,1 say dusplay + space(25 - len(dusplay))
  show gets
 return
 *--------------------------
 procedure commands
  do case
  case keys->charcode = 'P'     && push
    do push with dusplay
    dusplay = ""
  case keys->charcode = 'C'     && clear
    dusplay = ""
  case keys->charcode = 'Q'     && quit
    deactivate window form1
    close all
    cancel
  endcase
 return
 *--------------------------
 procedure operations
 parameter theOp
    raw1 = pop()
    raw2 = dusplay
    raw1 = iif(empty(raw1),'0',raw1)  && convert blank to zero
    raw2 = iif(empty(raw2),'0',raw2)  
    operand1 = val(raw1)    
    operand2 = val(raw2)
    && [insert division by zero check here]
    calc = operand1 &theOp operand2
    dusplay = ltrim(str(int(calc)))
 return
 *--------------------------
 procedure push(pushme)
  select stack
  append blank
  replace thevalue with pushme
 return
 *--------------------------
 function pop
  select stack
  result = ""
  goto bottom
  if .not. eof()
    result = stack->thevalue
    delete
  endif
 return(result)
 *--------------------------

 (end program code)

  Table: Keys

  Charcode Optype Op Descript        Xloc      Yloc

  0        K                         5.00     10.00
  1        K                         5.00      4.00
  2        K                        10.00      4.00
  3        K                        15.00      4.00
  4        K                         5.00      6.00
  5        K                        10.00      6.00
  6        K                        15.00      6.00
  7        K                         5.00      8.00
  8        K                        10.00      8.00
  9        K                        15.00      8.00
  P        C         Push           10.00     10.00
  +        P      +  Plus           20.00     10.00
  -        P      -  Minus          20.00      4.00
  *        P      *  Times          20.00      6.00
  /        P      /  Divide         20.00      8.00
  C        C         Clear          15.00     10.00
  Q        C         Quit            5.00     12.00

The other table, "stack", has only one column, "theValue".

[formatting re-work in progress]

-Top-

For anyone who cares, I have a tape calculator I wrote back in the Cretaceous (Fox 2.5b), that exhibits fairly ordinary desktop 10-key calculator behavior, except that it allows editing of the tape.

-- GarryHamilton