Foxpro was created in early 80's (originally as FoxBase - 1984?) by Fox software and supported on Mac OS, Unix, DOS, Windows platforms. It was known as the fastest database engine on PCs then. Later on 1992, unfortunately, it was acquired by Microsoft. After Microsoft's taking over, in 1994 Foxpro for DOS (FPD) and Foxpro for Windows (FPW) 2.6 released. At the end of 1995, Foxpro got the name "Visual" and the platform support was only limited to windows. It was also the first version of Foxpro where the language turned out to be Object Oriented.
Microsoft's official Visual Foxpro (commonly referred as just VFP) site describes it as:
Microsoft® Visual FoxPro® database development system is a powerful tool for quickly creating high-performance desktop, rich client, distributed client, client/server, and Web database applications.
Although it is an old language, it is still considered to be the easiest language for creating a data centric application rapidly for the windows desktop. If what you need is to create a data based application for windows desktop then choosing VFP you would really do that easily and fast.
Version | Released |
---|---|
FPW 2.6a | 1994-10-28 |
Visual Foxpro 3.0 | 1995-12-16 |
Visual Foxpro 5.0 | 1997-01-24 |
Visual Foxpro 6.0 | 2000-08-18 |
Visual Foxpro 7.0 | 2002-01-04 |
Visual Foxpro 8.0 | 2003-10-25 |
Visual Foxpro 9.0 | 2004-12-13 |
Visual Foxpro 9.0 SP2 | 2007-10-21 |
A simple way to catch unhandled errors (exceptions) in a VFP application is to use the ON ERROR command near the beginning of your main program.
The following ON ERROR command calls a method in the current program called "errorHandler". The values returned by ERROR (the VFP Error Number), MESSAGE (the VFP Error Message), PROGRAM (name of the currently executing program) and LINENO (the line number of the error) are passed to the errorHandler method.
ON ERROR DO errorHandler WITH ERROR(), MESSAGE(), PROGRAM(), LINENO()
A simple errorHandler method may look like the following.
PROCEDURE errorHandler
LPARAMETERS tnVFPErrorNumber, tcVFPErrorMessage, tcProcWithError, tnLineNumber
STORE 'Error message: ' + tcVFPErrorMessage + CHR(13) + ;
'Error number: ' + TRANSFORM(tnVFPErrorNumber) + CHR(13) + ;
'Procedure with error: ' + tcProcWithError + CHR(13) + ;
'Line number of error: ' + TRANSFORM(tnLineNumber) TO lcDetails
MESSAGEBOX(lcDetails, 16, "Unhandled Exception")
ON ERROR *
ON SHUTDOWN
CLEAR EVENTS
QUIT
ENDPROC
You can also change and restore the error handler in between. For example, at one point you want to open all tables in a folder exclusively, and if you can't you don't want to continue:
procedure DoSomethingWithExclusiveLock(tcFolder)
local lcOldError, llInUse, ix && by default these variables have a value of .F.
lcError = on('error') && save current handler
on error llInUse = .T. && new handler
local array laTables[1]
for ix=1 to adir(laTables, addbs(m.tcFolder) + '*.dbf'))
use (addbs(m.tcFolder)+laTables[m.ix,1]) in 0 exclusive
endfor
on error &lcError && restore old handler
if m.llInUse && couldn't get exclusive lock on all tables
close databases all
return
endif
* do whatever
endproc
Tip: Sometimes, especially during debugging, you would want to restore default error handler which allows you to break and step into the code where the error has occurred, then anywhere before where you got the error, temporarily adding:
on error
would do this.
In all languages traditionally the first example is printing "Hello World". Probably doing that is easiest in VFP:
? "Hello World"
Detailed instructions on getting visual-foxpro set up or installed.