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 ---- See also VisualFoxPro, ExBase ---- CategoryProgrammingLanguage, CategoryExample