Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
SET SAFETY
, Set(“Safety”)This is a rather friendly command. It can keep you from doing some really stupid things. When SAFETY is ON, FoxPro prompts you before overwriting files in most cases.
SET SAFETY ON | OFF
cSafetySetting = SET( "SAFETY" )
With SET SAFETY
ON, commands that completely overwrite a file bring up a dialog that tells you the file already exists and asks for permission to overwrite it. If you choose “No,” the operation is canceled. SET SAFETY
OFF bypasses that dialog.
The only problem with SET SAFETY
is that some file-writing commands bypass it. The Low-level File Functions
ignore SET SAFETY
, as do DDE commands (which have their own safety option).
SET(“SAFETY”), of course, gives you the current setting, as either “ON” or “OFF”.
* preserve old setting
cOldSafety=SET("SAFETY")
USE MyData
* turn it off
SET SAFETY OFF
COPY TO olddata FOR NOT DELETED()
* reset it
SET SAFETY &cOldSafety
SET SAFETY
ON can be a lifesaver while you’re doing development and testing from the command prompt, but we think it shouldn’t usually be used in an application. We understand what’s happening when a dialog box leaps to the fore and asks “Overwrite A837492484.TMP?”, but we should probably spare our end users these confusing and sometimes misleading dialogs. The exception is when the user is given the control to modify something and should be allowed to either rename or overwrite, just as he or she would in, say, a word processor. Check out the FILE()
function to determine whether or not you’re going to overwrite a file.
SAFETY is one of the many settings scoped to a data session, so you have to remember to turn it off somewhere early in your form class.