SET DEVELOPMENT, Set(“Development”), SET DOHISTORY, Set(“DoHistory”)

These commands are debugging aids. One big difference between them is that SET DEVELOPMENT is somewhat useful, while SET DOHISTORY is a nearly unusable relic.

Usage

SET DEVELOPMENT ON | OFF
cDevelSetting = SET( "DEVELOPMENT" )

SET DEVELOPMENT is most useful when you use a program editor other than the built-in FoxPro editor and when you don’t use Project Manager. Because we recommend the built-in editor and Project Manager, our view is that SET DEVELOPMENT’s usefulness is fairly limited.

When you use VFP’s built-in editor, something internal to the product makes sure that you always run the more recent version of the code; that is, code gets recompiled after it’s changed. With an outside editor, that internal process doesn’t occur. SET DEVELOPMENT ON tells VFP to check whether the source file is more recent than the compiled version of a program, and, if so, to compile it before running it. Of course, building an app with Project Manager does the same thing.

In older versions (before VFP 5), SET DEVELOPMENT had a couple of other, pretty much unrelated, behaviors. When it was ON, the Cancel item on the Program pad was enabled while a form or READ was active. In addition, with DEVELOPMENT ON, the Trace window opened automatically when a form hit a bug. In other words, life was a little simpler for you as the developer. That was the point. These behaviors appear to be gone in recent versions and we’re not sure we really care.

If you’re developing in the older versions, we recommend DEVELOPMENT ON while you’re developing and OFF in applications distributed to users. Consider using the value of VERSION(2) to toggle SET DEVELOPMENT in runtime environments. In newer versions of VFP, just leave this alone.

Usage

SET DOHISTORY ON | OFF
SET DOHISTORY TO [ HistoryFile [ ADDITIVE ] ]
cHistSetting = SET( "DOHISTORY" [, 1 ] )

SET DOHISTORY was a very cool command back in ancient Xbase times. It let you trace through a program and see the exact sequence of commands executed. We used it a lot in those days. But DOHISTORY’s days ended with the addition of the Trace window. Now, you can not only see what’s happening, but also interact with it.

But why not produce a history file anyway? That’s what you’re thinking, right? Because it’s slow. In VFP 6, a very simple test, just looping and displaying the loop counter, was slightly longer with DOHISTORY ON and set to a file. With DOHISTORY defaulted to the Command Window, though, it took about 1.5 times as long. Not so bad, right? But that was an I/O-bound process. We took the display out of the loop, so all we were doing was counting internally. With DOHISTORY ON, the loop took anywhere from 13 to 32 times as long, depending where the history was directed. (However, this is a tremendous improvement over VFP 3, in which the second test was 20,000 times as long with DOHISTORY ON.) Tests in VFP 7 indicate that the penalty has grown again, with a difference of about three orders of magnitude between DOHISTORY OFF and DOHISTORY ON. Besides, beginning in VFP 5, you can use Coverage and Event Tracking to see what’s going on. While VFP 5 didn’t provide a Coverage Analysis tool, just the raw logging capability, the Coverage Analyzer added in VFP 6 has made Coverage Analysis a regular part of our routine.

Like SET ALTERNATE, the two forms of SET DOHISTORY are independent of each other. To turn on history tracking and set it to a file, you have to issue both SET DOHISTORY ON and SET DOHISTORY TO a file. But don’t.

See Also

Set, Set Coverage, Set Debug, Set Echo, Set Step, Set Talk, Version()