Printing - FoxTalk - dFPUG-Portal

September 1996
3.0 or Not 3.0? That's the Question!
Art Bergquist
How do you tell if a table is a Visual FoxPro table or not? That's easy! You display the value of
SYS(2029) to return either a 48 (for a "Visual FoxPro table with or without a memo field"
message) or some other number (see VFP's online help for other possible values).
What if you want to determine if a table is a Visual FoxPro table but the table isn't open?
SYS(2029) returns a 0 ("No table open") in that case, so that isn't very helpful. You could open
the table first, but what if you need to know without first opening the table.
A technical way of doing this is to go to MS-DOS and use DEBUG to inspect the table's contents
(at the DEBUG dash (-) prompt type 'd100' and then type 'q' to Quit). A Visual FoxPro table has
a character zero (0) in the first byte (byte 0). Non-VFP tables (and other DOS files in general, for
that matter) have a non-zero value in their first byte.
The easier way is to use the following function (I've aptly named it VFPTABLE), which simply
reads the first byte (byte 0) and returns .T. if it's a character zero (0) and .F. if isn't. The function
thoroughly validates the input parameters by ensuring that a non-empty character string is
passed, that this string represents a DOS file that actually exists, and, finally, that the file can be
opened (in testing VFPTABLE from the Visual FoxPro Command window, for example,
C:\VFP\VFP.EXE couldn't be opened by FOPEN):
(1)

* Program Name: VFPTABLE.PRG
* Author: Art Bergquist
* Date: May 11, 1996
* Purpose: Determine if the specified file is a Visual
* FoxPro table or not
* Syntax: m.lIsVFP = vfptable("mytable.dbf")
* Input: tcFileName = Name of the DOS file to check
* Output: .T. = the DOS file is a Visual FoxPro table
* .F. = the DOS file is NOT a Visual FoxPro table
PARAMETERS tcFileName
#INCLUDE foxpro.h
PRIVATE ALL LIKE l_*
* name of the currently executing program
l_Program = PROGRAM()
DO CASE
CASE PARAMETERS() = 0
DO ErrorMsg WITH l_Program, ;
'You must supply a filename.'
RETURN .F.
CASE TYPE('tcFileName') # 'C'
DO ErrorMsg WITH l_Program, ;
'You must supply a *character* filename.'
RETURN .F.
CASE EMPTY(tcFileName)
DO ErrorMsg WITH l_Program, ;
'You must supply a non-empty filename.'
RETURN .F.
CASE NOT FILE(tcFileName)
DO ErrorMsg WITH l_Program, ;
UPPER(tcFileName) + ' does not exist!'
RETURN .F.
OTHERWISE
l_FileName = UPPER(tcFileName)
ENDCASE
* open the file (in read/only mode)
l_FileHandle = FOPEN(l_FileName, 0)
IF l_FileHandle = -1
DO ErrorMsg WITH l_Program, ;
l_FileName + ' could not be opened (by FOPEN).'
RETURN .F.
ENDIF
* Read the first byte
l_FirstByte = FREAD(l_FileHandle, 1)
* close the first file
= FCLOSE(l_FileHandle)
* First Byte = '0' if it's a Visual FoxPro table
* non-0 if it's not a VFP table.
l R t (l Fi tB t '0')

In what situation would you need to use such a function? I'm glad you asked. The following
program can be used to import/add FoxPro tables (.DBFs) to a Visual FoxPro database (.DBC).
If the tables you are adding are Visual FoxPro free tables, then no problem. If any table is a
FoxPro 2.x-style table, however, a dialog box with the following message will appear:
File '.DBF' will be updated to a new file format,
making it unreadable to previous versions of FoxPro.
This can be reversed with the 'COPY TO' command, and the
old table will be saved as a .BAK file. Continue?
> < No >
If you don't mind running this program interactively (in other words, answering Yes anytime the
program is about to add a FoxPro 2.x-style table), then you don't need to use the VFPTABLE
function. If, however, you would like to run the program in a batch, unattended mode (for
example, if you were looping through a list of .DBF files in a directory and calling
ADD2DBC.PRG for each .DBF file), use a program like ADD2DBC.PRG:
* Program Name: ADD2DBC.PRG
*
* Auto-answer the 'Table Update Warning' message
* that comes up when you add a FoxPro 2.x-style
* table to a VFP 3.0 database:
*
* File '.dbf' will be updated to a new
* file format, making it unreadable to previous
* versions of FoxPro. This can be reversed with
* the 'COPY TO' command, and the old table will
* be saved as a .BAK file. Continue?
*
*
* - -
PARAMETERS tcFileName
IF NOT VfpTable(tcFileName)
* Auto-answer the 'Table Update Warning' message
KEYBOARD 'Y' PLAIN
ENDIF
ADD TABLE (tcFileName)
* Auto-erase the .BAK file that was created
ERASE (tcFileName + '.BAK')
As you deal with the complications brought on by having to deal with two different types of
files2.x and 3.0 tables -- that have the same extension, it's useful to have tools on hand that make
short work of some of the problems you run into. This technique will help with a couple of those

problems.
Art Bergquist can be reached at 73762,3566@compuserve.com.
Visual FoxPro 5.0: A Sneak Preview
Whil Hentzen
The next version of Visual FoxPro has been in beta testing for a number of months. I'm finally
allowed to talk about it, so this month I'll give you a sneak preview of what you'll be using in a
few months.
Most FoxTalk readers won't get their hands on the new release for a few more months, so I'm not
going to spend this entire issue flooding you with information that you can't use for a while.
Nonetheless, you're curious and want information that can help you plan for the future, so I'll do
a preview in this month's editorial and then cover these new features over the next few months -and
when Visual FoxPro 5.0 hits the street, we'll get more detailed.
First of all, you might be asking, "5.0? Did I fall asleep? What happened to 4.0?" Nope, the
version of VFP that follows 3.0 is going to be named 5.0 -- just as Microsoft Word jumped from
version 2.0 to 6.0 a couple years ago. Going from 3.0 to 5.0 will keep VFP's numbering in sync
with the next releases of Visual Basic 5.0 and Visual C++ 5.0 (both of which are due out "real
soon now"). That, of course, brings to mind two questions: "First, why is it important to keep
version numbers in sync?" And, from the more thoughtful of you: "Will 5.0 suck up significantly
more resources like Word did when it went to version 6.0 from 2.0?"
Let's address the second question first: No, 5.0 won't require more resources -- in fact, one of the
primary design goals for version 5 is improved performance -- especially in areas that affect the
user interface, such as form instantiation, and in situations with 8M and 12M of RAM as well.
As far as the version numbers are concerned, remember that all three tools, Visual C, Visual
Basic, and Visual FoxPro, are going to be merged into a common development environment
called the Developer's Studio. We can look forward to concurrent releases of these products in
the future, so it will be easier to keep them straight if they're numbered similarly. Furthermore,
as each of these tools begins to use the same components, such as the Debugger or Report
Writer, it will again be easier to keep the revisions straight.
Now to the $64,000 question -- what's new in VFP 5.0? The fundamental goal of version 5.0 is to
provide the developer tools that we need in order to keep up with the amazing improvements in
the FoxPro language. When you fire up 5.0, the first thing you'll see is that the editor has been
colorized -- keywords, variables, comments, and the like all have their own colors -- and yes,
you can tailor those colors to suit your preferences. If you think quickly, the second thing you'll
notice is that by right-clicking you'll get context menu that extends the capabilities of the editor

-- the ones I like the most are the ability to clear the Command window and the ability to execute
the highlighted expression.
Touring around the interface some more will bring you to the Debugger, which is a whole new
animal. If you've seen the Debugger in Visual Basic or Visual C++, you'll be reasonably at
home. It's a completely separate process from Visual FoxPro, which means that it's a bit
disconcerting to see the entire window disappear behind the FoxPro window. Then you'll realize
that this means that using the Debugger is cleaner now, since it doesn't participate in any FoxPro
events.
The Debug window actually has five pieces: Trace, Watch, Locals, Call Stack, and Output. You
can select which of these components are displayed, and they can all be positioned at will. You'll
soon find that the 17-inch monitor that you've been eyeing is now a requirement -- and an even
larger one might not be that bad of an idea. Besides the obvious capabilities that these windows
give you, there are three more functions that I really like. Event Tracking allows you to send the
results of events you specify (such as particular methods) either to the Output window or to a
text file. Coverage logging allows you to see what code is being executed. You can also save a
particular Debugging configuration to a file to save time when setting up your development
environment. (Remember what a pain it was, having to type in variable and variable in Debug,
only to lose them if you had to exit out of FoxPro?) OK, and now that your appetite's been
whetted, we now have assertions in the language!
The next great feature that everyone wanted has to do with the way that classes are handled. For
instance, if you drag fields from the Data Environment to a form, you've been stuck with the
Visual FoxPro base classes -- there hasn't been a way, short of writing a builder, to tell VFP to
use your own classes instead. In version 5.0, however, the new default class and library
properties will allow you to assign a control type to a field: when you add the field to a form,
you'll create the exact control you want in one easy step.
The database container has been enhanced as well. For example, it will allow multiple users to
simultaneously create and modify objects within the same database, and the engine now supports
changes to values that violate rules. Both changes will solve a lot of headaches for you.
Probably the most requested feature for this version of Visual FoxPro has been outer joins, and
you won't be disappointed. You can create a variety of outer joins, queries that return "Top N"
results, and alias columns, and you can do this all in the Query and View Designers to boot.
The Form Designer has been enhanced as well. The Properties window has a ton of new
interface capabilities, including Property Zoom and keyboard navigation. There are additional
properties, events, and methods with many controls, and there's a whole slew of new OLE
controls as well. Other interface goodies include the ability to flip back and forth between Run
and Design modes with a click on the toolbar, the ability to manipulate multiple controls at one
time, and additional alignment capabilities.
You'll now be able to create SDI applications so that your application windows can be children
of the Windows desktop. And you'll be able to create context menus with the Shortcut Menu
Designer (your controls will be able to respond correctly to their new RightClick event). And for

those of you who've completely immersed themselves into the Windows environment, you can
create OLE servers with Visual FoxPro and other applications will be able to query FoxPro just
as FoxPro has been able to access other applications such as Word and Excel.
Remember that this was just a brief tour. I could have spent several pages (instead of one
paragraph) on the Debugger alone -- but it should give you a taste of what's going to be in your
hands in short order. You think VFP 3.0 was exciting? With 5.0, it'll just get better.
An Easier Way to Make Configuration Files
with GetConfig()
Bill Budney (2)
Most applications require some configuration information such as paths to files, information about
a user, whether you are running in development mode or as a user, optional features, and so on. If
you're like me, you've probably been using either GetEnv() to query DOS environment variables or
a configuration table in your application. However, I find both of these techniques annoying at
times, so recently I started using a third alternative that I'd like to share.
Several things bug me about GetEnv(). First, I have to reboot to change an environment variable.
If I'm testing or debugging an application, I sometimes want to flip back and forth between
Development mode and User mode. If my application tests for something like GetEnv("User")
="DEVELOPMENT", then I have to reboot to make this change. Another annoyance is that I
have to remember to set the environment variable on every user's PC. Even on a LAN, user's
boot drives frequently aren't published on the network, so these edits either have to be made by
the user or by going to each PC and editing AUTOEXEC.BAT, unless the system manager has
set up a LAN-based startup script. If some program or well-intentioned system manager disables
the settings in AUTOEXEC.BAT for some reason unrelated to my program, it could break my
application.
A configuration table can be modified without rebooting the computer, but it requires a
development version of FoxPro (and a user comfortable enough with BROWSE to make the
necessary modifications), or a dedicated maintenance form to modify the table. The problem
with a dedicated form is that some setup options might be required just to run the program, but if
the options are set incorrectly, the user might not be able to get to the maintenance form to
change it. And, although BROWSE isn't particularly difficult, some users can't be trusted with it.
Finally, some clients don't even have a development version of FoxPro handy, so they couldn't
make the changes even if they knew how.
CONFIG.FPW
The solution that I like the most is to use a text-based configuration file. Some of my apps have
an application-specific .INI file, which I can read or write to using the Windows
GetPrivateProfileString and WritePrivateProfileString API functions. However, FoxPro already

equires a text-based configuration file (CONFIG.FPW), so why not put my setup information
there? I can use either a LAN-wide default CONFIG.FPW or let each user have their own. Often
I do both -- using a default CONFIG.FPW on the LAN, while letting users override the defaults
with their own CONFIG.FPW.
GetPrivateProfileString is easy to use on .INI files. The trick to using it with CONFIG.FPW is to
add a section header. FoxPro will ignore lines that it doesn't understand, so you can safely add
lines to CONFIG.FPW without generating an error. I use a single section called [Common], but
you can use any section name you want, or you could get fancy with additional sections. (By the
way, you can modify the current CONFIG.FPW quickly with the command MODIFY
COMMAND sys(2019) ).
A sample CONFIG.FPW might look like this:
* CONFIG.FPW
talk = on
safety = on
exclusive = off
resource = C:\foxuser
[Common]
PATH = c:\vcommon;c:\common
User = Development
Compare = c:\nu\fcompare.exe
Default = C:\Dev\LT2
_GENMENU = 'c:\vcommon\GENMENUX.PRG'
command =do c:\vcommon\bbStart.prg
Calling GetConfig()
Using GetConfig(), I can find the values for any of the "keys" in the [Common] section. (A key
is the value to the left of the equals sign, while its value is the text to the right of the equals sign.)
GetConfig always returns values in uppercase, so you can count on that when you test values:
lcPath = GetConfig("Path")
Here's another example:
if GetConfig("User") = "DEVELOPMENT"
*-- Turn on Developer menu pad or other features here
endif
How it works

GetConfig is a special case of calling GetPrivateProfileString. GetConfig assumes that the file
you are reading is the current Config.FPW, and that all of your keys are in the [Common]
section. Three lines of code are at the core of GetConfig:
lnHandle = RegFn("GetPrivateProfileString", ;
"CCC@CIC", "I")
lcRetVal = SPACE(200)
=CallFn(lnHandle, "Common", tcKey, "BogusValue",;
@lcRetVal, LEN(lcRetVal), sys(2019))
The RegFn call registers the GetPrivateProfileString API function. If you look up
GetPrivateProfileString in C:\VFP\WIN32API.HLP, you can get a clue about the calling
parameters. I've found that converting the documentation (written for C programmers) into
FoxPro code isn't difficult, although it can be a bit confusing until you get the hang of it.
The second line creates a memory variable with sufficient space to store the results from the API
call. This is a necessary step when calling some Windows API functions. If you pass a variable
by reference, you must initialize the variable first. This is because C (which is the language that
the API function is written in) requires variables to be initialized before use, and it can't change
the size of the variable on the fly as FoxPro can.
Finally, the CallFn line makes the actual call to GetPrivateProfileString. Table 1 lists the
parameters passed.
Table 1. The parameters that can be passed to GetPrivateProfileString.
lnHandle The "handle" returned by RegFn.
"Common" Hardcoded because GetConfig assumes you are lookingat the [Common] section.
tcKey The key to search, as passed to GetConfig. Ex: GetConfig("User").
"BogusValue" A seed for the key value, in case the value is emptyor the key is missing.
@lcRetVal The variable (passed by reference, as a "pointer")where the results will be stored.
LEN(lcRetVal) The size of lcRetVal (required by the API).
sys(2019) The current Config.FPW in use.
GetPrivateProfileString returns lcRetVal as a null-terminated string. A null is an ASCII 0. To
make it a suitable FoxPro character variable, simply strip out the null. That's it!
The entire program looks like this:

*FUNCTION GetConfig
* Abstract...: Reads info from the current CONFIG.FPW.
* : Requires a [Common] "section" marker in
* : Config.fpw similar to .INI files.
* : For example:
* :
* : [Common]
* : Path = MyPath;YourPath
* :
* Parameters.: tcKey is the key to read
* : ("Path") in the above example.
* : Case insensitive.
* Returns....: lcRetVal
* Author.....: Bill Budney
* Copyright..: 1995-1886, BBA Technologies
* Date.......: May 18, 1995
PARAMETERS tcKey
PRIVATE lcRetVal, tcKey
IF NOT "FOXTOOLS" $ UPPER(SET("library"))
SET LIBRARY TO home() + "foxtools" ADDITIVE
ENDIF
*-- Register the GetPrivateProfileString API.
lnHandle = RegFn("GetPrivateProfileString", ;
"CCC@CIC", "I")
*-- Make some space for the return value.
lcRetVal = SPACE(200)
*-- Call the API.
=CallFn(lnHandle, "Common", tcKey, "BogusValue", ;
@lcRetVal, LEN(lcRetVal), sys(2019))
*-- Remove the nulls.
lcRetVal = TRIM(STRTRAN(lcRetVal, CHR(0), ""))
IF lcRetVal = "BogusValue"
lcRetVal = ""
ENDIF
RETURN Upper(lcRetVal)
Summary
GetConfig is a quick and easy way to read configuration information from CONFIG.FPW.
GetConfig doesn't require rebooting, global variables, or custom _Screen properties. It doesn't
even require a copy of FoxPro to visually inspect or modify the file. The result is fewer
configuration files to worry about and a quick and easy way to poll for setup information.
GetConfig will work with all versions of Windows and all versions of FoxPro for Windows and
Visual FoxPro. If you're using FoxPro for DOS or Mac, then you'll need to seek alternative

solutions.
Bill Budney is located at BBA Technologies, 1401 Beacon St., Suite 206, Brookline, MA 02146.
617-730-9798, budney@bbatech.com.
Create an Automated Development Log
Doug Hennig
Logging programming changes has helped the staff at Stonefield Systems Group in a lot of ways,
including systems documentation and tracking. It also serves as the foundation for an automated
system of generating incremental distribution files when a new version of an application is released.
This month's column provides an automated logging tool that can help you manage these issues.
More than a decade ago, I realized that the way I was managing software development wasn't
working. I'd get a support call from a client, spend a long time trying to figure out why the client
got an error message but my version ran fine, only to discover that several program components
(I like to use the generic term "modules") on the client's system weren't the same as the ones on
mine. Sometimes this was caused by my not installing all the pieces at the client site when a new
version was released, sometimes it was because the client didn't install the new version I sent
them. Either way, I couldn't just install my copy of the modules on their system; what if those
modules impacted other pieces of the program or what if they expected that other things (like
table structures) had changed? I needed to know exactly what differences there were between the
version the client had and the one I had.
If you're like me, you're so busy you can hardly remember what you did last week let alone the
details of what changes you made months ago. I needed a better way to determine what changes
had been made to each module in an application and when those changes were made. I decided
to log every change I made to every component in every application I've created since then.
Initially, I logged the changes in a Development Worksheet form, but later I decided to create a
FoxPro application and log the changes to a table, because it made searching for a specific
module (especially library routines used in many applications) easier. Our log files at Stonefield
now have more than 35,000 records.
In this month's column we'll look at a development logging system we use at Stonefield to record
what changes were made, when they were made, and to what modules in the applications and
tools we develop. Since we started using this little tool, it has saved us on numerous occasions
and also serves as the basis of an automated system of delivering updates to people who
purchase our tools.
(3)

Advantages of logging changes
We've found that logging changes made to modules gives us a lot of advantages:
• The documentation for all changes made to all modules in an application are in one place.
You don't have to scan through a dozen program files looking for change comments.
• Changes made to library routines can be examined when an older application using those
routines needs to be maintained. In the past, we found that changing a library routine
occasionally broke applications we hadn't looked at in some time after the application
was rebuilt using the new library routines. The problem, of course, is that the only way to
find out which parts of the application may have been affected is to retest everything.
Using the development log, you can quickly check which library routines have changed
since the application was released and concentrate on what impact those changes may
have rather than worrying about every library routine.
• What if a client didn't install the last update you sent them? This is especially problematic
if you have many customers using the application over a wide area. For example,
Stonefield maintains a retail pharmacy application called Pharmacy Partner that's used
by pharmacies all over two Canadian provinces. It isn't unheard of for a pharmacy to not
install an update we send to them. When it comes time to install yet another update or to
answer a support call, it's usually important to know what differences there are between
older and newer versions. Having a log of changes allows you to go over the incremental
differences between the versions and prepare to handle any issues that arise because of
these differences.
• In his book Code Complete, Steve McConnell says that frequently changed routines or
those previously found to be error prone are the most likely to continue to contain errors.
By examining the history of the modules in an application, you can determine which
modules have been edited the most, and target your efforts at cleaning those up or even
completely rewriting them to eliminate the problems.
• In my experience, if something that used to work stops working, it's usually not because a
file got corrupted but rather because something was changed. The most likely culprit is a
recently changed program. By looking at the development log, you can determine which
modules were changed and when. The problem is likely related to one of the most recent
changed modules.
• In a multi-developer or multi-project environment, a project manager can tell what others
have done on a project, which bugs have been fixed, which enhancements are finished,
and so forth. Frequently I and other Stonefield developers are working on several projects
at once, and the development log is another tool that helps me keep track of where I and
the others are at in each one.
The big payoff: incremental distribution
As important as logging module changes has been to us, we recently discovered an even more

useful benefit: automating incremental distribution.
As a tool vendor, we're constantly maintaining our products: adding new features, correcting
defects, and so forth. The problem: how do you distribute these changes (especially bug fixes) on
a timely and cost-effective basis to a large installed base? Until recently, we would send out a
"maintenance release" on a floppy disk, but this gets expensive, takes time to coordinate and
distribute, often doesn't get the changes out to customers as quickly as they're made, and can
cause a lot of headaches (if even five percent of the disks arrive unreadable, each of those
customers is going to phone and we'll have to send them a replacement disk). We thought about
making the new release available on our Web site, but since a complete product barely fits on a
disk even after it is compressed, that would make for large files to download. Also, how do you
prevent people who didn't buy your product from downloading the complete product and getting
it for free?
The solution we came up with was to electronically distribute an incremental set of changes.
This keeps the download file small and allows us to post a new release on our Web site as often
as changes are made. The incremental changes are built into a FoxPro APP that checks for the
existence of a key file that's part of the original product to ensure the update is being installed by
a legitimate customer. If it can't find the file, it displays an error message and terminates.
Otherwise, it copies the incremental changes over the original files and updates the product to
the latest version.
The only downside to this process is managing the creation of the incremental file. How do we
track which changes were made from one release to the next so we can ensure all changes are
distributed? Wait a second, isn't that what the development log keeps track of? What if we could
create an automated routine that reads the development log file, picks up the name of all modules
changed in a given release, and then packages them for distribution? We'll see how two routines,
MAKEUPD and INSTUPD, do just that.
Using the development log
The development log tool, DEVLOG, is provided in download file _HENNIG.EXE in both
Visual FoxPro and FoxPro 2.x (cross-platform DOS and Windows) versions. When you run the
appropriate version of DEVLOG.APP, it installs itself in the FoxPro system menu bar (under the
Tools pad in the case of the VFP version and under the Program pad in the case of FoxPro 2.x),
so it's quickly available when you need it. I run DEVLOG.APP from my FoxPro startup program
(VFPSTART.PRG in the case of VFP and FOXSTART.PRG in the case of FoxPro 2.x), so it's
installed automatically whenever I start up FoxPro.
Figure 1 shows the VFP version of DEVLOG (the user interface for the FoxPro 2.x version is a
little different but the functionality is similar). To define the applications you're working on in
DEVLOG, choose the Application page, click on the New button, and enter the name of the
application and a shorthand code for it. You can also delete applications in this page; doing so
also deletes all log entries for that application, so you're prompted to ensure you want to do that.
The development log page is where you make log entries. Select the name of the application
from the Application drop-down list. Then enter the version number of the application and the

date (the default is the current date, or the date previously entered; this is handy when you are
entering batches of records at a time). Next, either enter the name of the module (.PRG, .SCX,
.FRX, and so on) or choose it from the existing entries in the Module combo box (when you
select the application, the Module combo is populated with all modules from existing log entries
for this application). Enter a description of the changes made in the Description edit box and
choose the Save button. The Module and Description controls clear, ready for you to enter the
next log entry for the same application, version, and date.
You can navigate through log entries on the List page. If you wish to edit one of the entries, click
on the Edit button to activate the first page and place the selected entry in it. If you wish to add a
new entry without saving the selected one, click on the New button.
A closer look at the development log
Unfortunately, the code for DEVLOG, MAKEUPD, and INSTUPD is too long to publish here
(it's available in download file _HENNIG.EXE), but we'll look at a few interesting features of
these routines.
DEVLOG.PRG is a program used by both the VFP and FoxPro 2.x versions of the development
log as the main program in the application. This means it must handle differences between these
versions. For example, while LOCAL is a valid command in VFP, it gives a compile error in
FoxPro 2.x, so DEVLOG.PRG uses PRIVATE instead.
If DEVLOG.APP is called without any parameters, it assumes this is an "installation" call, so
DEVLOG.PRG adds two new bars to the appropriate pad in the system menu bar (under Tools
for VFP and Program for FoxPro 2.x). The first bar is simply a separator line while the second is
"Development Log." Of course, if DEVLOG.APP has been run before, we don't want to add it to
the menu again, so we must handle that case:

lnBar = 0
lcPrompt = 'De\

lcDirectory = substr(sys(16), ;
rat(' ', sys(16)) + 1)
lcDirectory = left(lcDirectory, ;
rat('\', lcDirectory))
on selection bar lnBar + 1 of &lcPad ;
do locfile('&lcDirectory.DEVLOG.APP', 'APP', ;
'Locate DEVLOG.APP') with 'Run'
set sysmenu save
Notice the DO command passes a string to DEVLOG.APP. This is so when it's called from the
menu, it isn't an "installation" call. The string passed is unimportant, but I set it to "Run" so it's
obvious what we're doing. Also notice SET SYSMENU SAVE is used so if you later use SET
SYSMENU TO DEFAULT, Development Log is still available in the menu.
DEVLOG.PRG creates the tables it needs (DEVLOG.DBF, DEVAPPL.DBF, and
DIRECTRY.DBF) if they don't exist. However, in VFP, we need to ensure that these tables
aren't inadvertently added to any open database, so we need to use the FREE keyword in the
CREATE TABLE command. Since this would cause an error in FoxPro 2.x, we create a variable
called lcFree that either contains the word FREEor a blank string, depending on the version, and
macro expand it in the CREATE TABLE statement. Thus, in VFP the effective command is
CREATE TABLE FREE, while in FoxPro 2.x it's CREATE TABLE. To ensure that these tables
are created in the same directory as DEVLOG.APP, which may not be the current directory, we
use the same lcDirectory variable defined earlier as the directory where the tables should be
located:
lcFree = iif('Visual' $ version(), 'free', '')
create table (lcDirectory + 'DEVLOG') &lcFree ;
(APPLIC C(10), ;
VERSION C(4), ;
DATE D, ;
MODULE C(12), ;
DESCRIP M)
If DEVLOG.APP isn't called as an "installation" call (in other words, you selected it from the
menu), it needs to run the appropriate routine: DEVLOG.SPR in the case of FoxPro 2.x or the
DEVLOG form in the case of Visual FoxPro. Since these two routines are called differently,
DEVLOG.PRG must handle it:
lcRun = iif('Visual' $ version(), ;
'form DEVLOG', 'DEVLOG.SPR')
do &lcRun with lcDirectory
In the VFP version of the DEVLOG form, we want to enable only the Save button when all the
necessary information has been entered. The following code was placed in the

InteractiveChange() method of each control:
This.Parent.cmdSave.Refresh()
This.Parent is used instead of Thisform because the Save button is sitting on the same page in a
pageframe as the other controls. The Refresh() method of the Save button has the following
code:
with This.Parent
This.Enabled = not empty(.cboApplication.Value) and ;
not empty(.txtDate.Value) and ;
not empty(.cboModule.DisplayValue) and ;
not empty(.edtDescription.Value)
endwith
This ensures that as soon as the user starts typing something in the last field needing to be filled
in, the Save button is enabled. Putting the call to cmdSave.Refresh() in the Valid() method of
each control instead of InteractiveChange() would result in the Save button staying disabled until
you try to exit the control.
Because FoxPro 2.x doesn't easily support BROWSE windows integrated with READ windows,
the list of log entries is implemented as a "pick list" routine instead. When you choose the Find
button, you're asked to select a module. Doing so then brings up a BROWSE-based pick list of
all log entries for that module. Highlighting one record and pressing Enter brings that record up
for reading or editing.
MAKEUPD and INSTUPD: Incremental Distribution
MAKEUPD is provided as a form in VFP (DO FORM MAKEUPD) and a project and associated
files that you can use to create an APP in FoxPro 2.x (DO MAKEUPD). MAKEUPD is simple:
it asks you to specify which application you're interested in (including the version) and then
creates an incremental distribution file for that application. It does this by opening
DEVLOG.DBF, finding all entries for the specified application and version, and then reading
each file specified in the MODULE field in each log record into the memo field of a table called
UPDATE.DBF using the APPEND MEMO FROM command. This table thus contains the
contents of each file changed in this version of the application.
In addition to DEVLOG.DBF, MAKEUPD relies on a table called DIRECTRY (which is created
the first time you run DEVLOG) that contains the directories where source code can be found for
each version of an application. MAKEUPD uses this table so it can find where each of the
modules logged in DEVLOG.DBF is located. If the source code for an application is spread out
over more than one directory, create one record in DIRECTRY for each directory in the
application. MAKEUPD will automatically recurse to each subdirectory under the defined
directories, so you only have to define the top level directories used for each application. While
you're filling out the contents of DIRECTRY, enter into the KEYFILE field the name and

location of a "key" file that must exist on the customer's site to ensure they're a valid owner of
the product.
INSTUPD.APP is used at the customer site to update their copy of the application with the
changed files. The UPDATE table created by MAKEUPD is included in the INSTUPD project.
The main program in INSTUPD.APP is very simple: it ensures the "key" file for the application
can be found (MAKEUPD puts the name of this file, stored in DIRECTRY, into
UPDATE.DBF), then it copies out each file from the memo field in UPDATE.DBF, overwriting
any existing file on disk or installing a new file. Thus, INSTUPD updates the application with
the most recent set of files. To create INSTUPD.APP, simply rebuild the INSTUPD project after
running MAKEUPD.
Improvements
Although DEVLOG.APP has done yeoman service for us, several improvements could be made:
• There's no built in reporting function. If you need to print reports by module, date, or
application, those reports can easily be created.
• Since VCXs can include many classes and each class can have many methods, additional
fields could be added to DEVLOG.DBF so you can indicate which class inside the VCX
was changed and which method was affected by the change if you want this level of
detail in discrete fields.
• The "make update" facility could be integrated with DEVLOG.APP.
Conclusion
If you're using version control software to manage application development, you probably
already have the logging functionality described in this article. However, many of the smaller
development shops I talk to don't use such software. If you fall into this category, you'll find
DEVLOG as useful as we have.
Next month we'll look at some "best practice" ideas for data handling in real world situations.
We'll explore some strategies for handling multiple sets of data (such as test and production
versions) in FoxPro 2.x and VFP, handling data validation errors, and other issues that come up
in most applications.
Doug Hennig is a partner with Stonefield Systems Group Inc. in Regina, Saskatchewan, Canada. He is
the author of Stonefield's add-on tools for FoxPro developers, including Stonefield Data Dictionary for
FoxPro 2.x and Stonefield Database Toolkit for Visual FoxPro. He is also the author of The Visual
FoxPro Data Dictionary in Pinnacle Publishing's "The Pros Talk Visual FoxPro" series. Doug has
spoken at user groups and regional conferences all over North America. 75156,2326@compuserve.com.
Use Stonefield AppMaker to Create Custom

Components
Kelly Conway
If you've developed FoxPro applications for awhile you've experienced déjà vu when beginning
another application from scratch. You create a directory structure here and copy a few programs,
screens, and menus there. You may ask yourself, "Haven't I done this before?" You promise
yourself that one of these days you'll write a program that will set it all up. Then, as the application
progresses, you find yourself laying out and coding what seems like your one-millionth
general-purpose data-entry screen. Wouldn't it be nice if you had a tool that would generate those
standard screens for us?
In 1994, Stonefield Systems Group Inc., makers of the popular Stonefield Data Dictionary
(SDD) (reviewed in the February 1996 issue of FoxTalk), released a new product named
Stonefield AppMaker. AppMaker addresses the problem of generating standard screens, and
more.
A complete, cross-platform application framework, AppMaker creates a standard directory
structure and project files and also copies the necessary library files, main program, and menu
files into the new directories. Then, after you've used SDD to define your tables (or import
existing table definitions), AppMaker uses that information to quickly generate screens that, for
most tables, might be used unmodified in the delivered application.
But that's just the beginning. Read on to discover the wealth of features that AppMaker helps
you to deliver in your applications.
Using AppMaker to get started
Rather than give you a laundry list of features, I'll relate those features by describing my recent
experience using AppMaker to create a quick prototype of an application. I was charged with
giving the client an idea of what we could do for them in FoxPro for Windows "without
spending too much time. And, oh yeah, it would be nice if the prototype was complete enough
that we could install it on the client's machine and let them play with it after we leave."
How much time is "too much time?" Who knows? But, having used AppMaker to develop a few
applications already, I knew that it was my best bet for creating a robust prototype in the shortest
amount of time. I spent about an hour making a list of the functionality I wanted the prototype to
have and then another hour sketching out and creating the tables and relationships.
At 10 a.m. I created a directory for the prototype as well as a program called SETPATH. I used
SETPATH to call AppMaker to ensure that its menu pad (Application) was added to the FoxPro
menu bar and to issue the SET PATH command to include all of the subdirectories I needed to
access.
I then chose the New Application option from the Application menu pad. After filling out
(4)

information such as the name of the project, the directory where it would be located, whether the
application would require users to login upon startup, and which platforms would be targeted,
AppMaker created a directory structure containing all of the files I needed for a new application.
This included a set of project files that already contained references to the standard application
objects (most of which were located in the shared directory structure, but some of which were in
the project directories so that they could be modified for each project).
At 10:10 a.m., I built the project into an .APP and started it. After logging in with the user name
and password of SUPER, I saw a logo screen that contained the name of the application I had
just created. I also noticed a fully functional menu system with File, Edit, Record, Screens,
Report, Utilities, Windows, and Tools pads.
The File pad contained Print Setup and Exit options. The Edit and Record pads were disabled
(more about them later). The Screens pad contained no bars. The Reports pad contained fully
functional options for Ad-Hoc Reports and Mail Merge. The Utilities pad's functions, Change
Password, Customize, Reindex, and Security were also functional, as were the Cycle, Close All,
About, and Help options of the Windows menu pad. The tools pad, available because I had
inserted SET DEVELOP=T into the AUTOEXEC.BAT file, contained several functional options
including Edit a Program, Edit Help, Suspend, Trace, Debug, Command window, View, and
Array Browser.
Not bad for 10 minutes worth of work (15 if you include the testing). At 10:15 a.m., I chose Data
Dictionary from the Application and was presented with the familiar Stonefield Data Dictionary
screen. I batch-added the tables I had created and entered a long description for each table, field,
and index. I set up some of the tables to have a primary key that would be generated
automatically by calling the Stonefield AUTOKEY() routine. I marked each of the tables (11 in
all) to be auto-opened, reportable, and available in mail merges.
I also defined each of the fields to be reportable and sortable and each index tag to be
user-selectable as the current table order. In addition, I defined which fields were allowed to be
left blank. I didn't do it for this prototype, but I could have defined any of the following screenoriented
items for each field as well: picture, default value, when code, valid code, message,
error, range, and help text. These tasks lasted until 11:30 a.m.. Man, am I hungry.
At 12:30 p.m., I began to put the finishing touches on the table definitions and set up the
relationships between the tables. The data dictionary even allowed me to specify referential
integrity options for each relationship. For instance, I set it up so that the user wouldn't be
allowed to delete a customer if they had one or more projects defined. But, if a project ID
number got changed, it was allowed, but the change was cascaded into the project products table
that contains the project ID as a foreign key. The options are, in fact, very similar to those that
are available in Visual FoxPro.
Having a fairly complete definition of the application's data, I turned my attention to defining the
user interface.
Creating quick screens, reports, and menu options

At 1:00 p.m., I used the Quick Screen option of Application to generate data-entry screens for
the application's seven "look-up" tables. At 1:15 p.m., I built the application and tested those
data-entry screens as well as the Ad-Hoc Reporting, Mail Merge, Reindex, and Update Table
Structures options. Each worked flawlessly in a modeless, event-driven environment.
However, AppMaker added the options to call my screens to the File menu pad. Since, I wanted
these options to show up under my Screens menu pad, I had to do a little work in the menu
builder to transfer those options.
This might be a good time to mention the BASEDEF project that Stonefield uses to create new
applications. BASEDEF is a regular FoxPro project that isn't meant to be built. Rather, you can
modify its components so that the new applications AppMaker generates take on the
characteristics you want. The default main menu in BASEDEF doesn't contain a Screens pad and
it places the reporting options on a pad named Print.
I added the Screens pad and renamed Print to Reports in BASEDEF's SYSMAIN menu. From
that point on, all of my new application menus contain Screens and Reports pads. I could've also
modified the Quick Screen process to add screens to my Screens menu pad rather than the File
pad.
Now, back to the prototype. After moving my menu options around and testing what had been
built to this point, it was approaching 3 p.m. Time to move on to some reports. I ran the
application and created quick reports for the seven lookup tables from the Ad-Hoc Reports
option. Quick reports automatically used my field descriptions as report headings.
These reports (and the look-up table screens too, for that matter) probably will be delivered
unchanged in the final version of the application. Using the Ad-Hoc Reporting facility, the user
will be able to specify order and filter conditions each time they run any of the reports. They
even can save filters to be reused at a later date. About the only thing I've found that can't be
done in the Ad-Hoc Reports is filtering on a non-field expression (for example, NOT
DELETED()).
Okay, it's 3:30 p.m. and I have a modeless, event-driven application that allows maintenance and
reporting of seven small tables as well as a login screen, user maintenance, security, password
change, customization (by user) options, ad-hoc reporting, mail merge, and table utilities
(reindex, pack, and update table structures). The maintenance tables share a toolbar that sports
nice-looking picture buttons for Add, Edit, Delete, Top, Prior, Next, Bottom, Find, List, Save
Cancel, and Close functionality.
The List option invokes a BROWSE window with incremental search capability on any column
as well as the ability to sort on any column by moving the cursor into it. Find is a
query-by-example implementation that allows the user to enter data into any combination of the
screen's fields and then looks for matching records. If more than one match is located, the user is
presented those record in the List function so they can choose the appropriate one. If you have
the PhDBase text-search library installed, AppMaker automatically will use PhDBase indexes to
support quick searches for the entered data contained anywhere in the corresponding field.

The Record menu pad contains an entry for each of these toolbar buttons as well as additional
options for duplicating and filtering records. You may choose to use a different toolbar, such as
one with text instead of pictures. Or you can create your own toolbar that calls the AppMaker
functions. You can also tell AppMaker to generate push buttons in the screen and do away with
toolbars altogether.
The Edit menu pad contains the usual fare for cutting, copying, and pasting text.
Oh yeah. The documentation says there's also a built in error handler, but I haven't seen it yet.
There's still plenty of time in the day, so I press on.
Creating more screens
The prototype I'm building contains four main tables (in addition to the seven look-up tables I
already handled). One is a customer table that contains about 30 fields, which is too many fields
to put onto one screen (for my taste anyway). Sounds like a good time to try Steven Black's
TABS driver for GENSCRNX. It uses GENSCRNX to create screens (actually screen sets) that
mimic the tabbed screens that have become so popular in the last couple of years.
Never used GENSCRNX? Not to worry -- I hadn't either, before AppMaker came along. It turns
out that I've been using it all day now and didn't even know it. Stonefield wrote some
GENSCRNX drivers that take care of writing the code to make AppMaker screens work in their
event-driven framework and to be data-driven (use information stored in the data-dictionary such
as the picture, default, message, and help clauses I mentioned earlier). Stonefield did the work of
setting up GENSCRNX for me.
But to use the TABS driver, I had to do a little work (very little) myself. I read the page about
creating tabbed screens that appears in the AppMaker manual. Then I looked at (and copied) the
example tabbed screen from the sample application that came with AppMaker to create my first
tabbed screen. Between 3:30 and 5 p.m. I created three tabbed screens (the fourth main table
ended up being another simple screen that gets called from one of the other three screens -- more
on that later). One has two tabs, one has three tabs, and the other has four.
Like any other relational database application, each of the "main-table" screens contains fields
that link the records to the other main tables and to the lookup tables. Between 5 and 5:30 p.m., I
set each of those fields up so that they'll validate the user's entry and bring up a list of valid
choices if the entry isn't found. This functionality is provided by AppMaker's LOOK_UP
procedure. Optionally, I could allow the user the choice of adding a new record to the related
table and pass a parameter to LOOK_UP indicating which of the data-entry screens to bring up
in add mode for this operation.
In fact, I can use that add-mode functionality in other places. Remember that fourth table I
mentioned earlier? It serves as a child table to one of the other three "main" tables. The related
records from the child table are displayed in a list box on one of the tab pages of the parent table.
Below that list box are buttons for adding, editing, and deleting child records. The Add button
calls the child screen in add mode and returns immediately after the user chooses either Save or
Cancel. The Edit button calls the child screen with the current record in edit mode and also

eturns after Save or Cancel is selected. The Delete button asks for confirmation and then
removes the selected child record from the table.
Why do I go into this in so much detail? We've all written this type of parent-child screen over
and over, haven't we? Not me any more. All I did was draw a box where I wanted the child list
box to appear and added a couple of GENSCRNX directives to the boxes comment snippet. I
also created the Add, Edit, and Delete buttons and added a GENSCRNX directive to each of
their comment snippets. AppMaker took care of the rest when I generated the screen.
As an aside, AppMaker also allows you to create screens that contain integrated BROWSE
windows by using the INBROWSE driver for GENSCRNX. The documentation is very thorough
(seven pages) and the sample contains an example or two. I've used this feature and it does work.
But I must warn you that, like any other method of integrating screens and BROWSE windows,
the results aren't perfect. I got most of the functionality that I wanted in just a few minutes. But
the last few things just aren't going to happen in any integrated BROWSE solution, primarily
because of the BROWSE window's lack of Activate and Deactivate "events."
Well, it's been a good day. It's nearly 7 p.m. and the prototype is ready to go. The client is going
to love it! Of course, we'll have some more work to do after they accept our proposal. But
AppMaker has created a good portion of the finished application for us. And it's all
well-documented FoxPro programs and screens. AppMaker also contains several other
data-driven routines not even mentioned here that will help us create most of the other options
we'll need to add to this application.
Modifying and extending AppMaker
No matter how good a development framework is, there are always times when you need to do
something a little differently or perhaps add something new that the framework doesn't address.
This fact probably dissuades more developers from using third-party frameworks than any other.
How can you make changes and additions to the product and still be able take advantage of the
vendor's upgrades?
In most respects, AppMaker isn't much different from most products on this issue. If you make
changes to the framework, you'll have to do some work to merge those changes into the next
update that comes from Stonefield. In addition to the obvious need to document these changes,
here are a few strategies that help make this a less painful experience:
1. When possible, externalize your changes. This means you should make your changes in a
separate program that can then be called from the appropriate place in the framework program
that needs modification. Then, when you receive an update, you need only to insert the call to
your external programs into the new version.
2. Create a subdirectory of your project to contain modified versions of the framework
components. I call mine STONEMOD. I make a copy of the program or screen that needs to be
modified, make the modification there, and point the project to that version rather than the
centrally located one. With this strategy, you may never need to merge your changes into an
updated version. You really only need to do so when the version adds a feature that your client

wants to have.
3. If you're adding new functionality, place it in a separate subdirectory within the AppMaker
directory structure. I call mine CUSTOM. This strategy will allow you to keep track of your
enhancements without fear of overwriting them if Stonefield adds a feature with the same name
in a future update.
4. When you make a change, send a message to Stonefield to let them know what you have done.
If the change has generic appeal, you may find that Stonefield will add it to the product (and give
you credit in the comments), reducing the amount of work required to merge your changes into
future updates.
Using these strategies, I recently upgraded a client's application from an older version of
AppMaker to the latest one in a couple of hours. When I was done, the application contained
several enhancements, any one of which would have taken longer than that to implement.
A different strategy
So you just can't buy into someone else's application framework lock, stock, and barrel? Well,
there are still ways that you can use Stonefield AppMaker. You could use the product to get
ideas for designing your own framework (although you'd probably find it much easier to start
with AppMaker and tailor it until it fits -- gaining the benefits of using the framework from day
one).
You also can use some of the data-driven routines to enhance existing applications. For instance,
I'm saddled with maintaining a huge application that originally was written in dBASE IV. (Who
isn't?) In less than a day I added all of that application's tables to Stonefield Data Dictionary,
provided English descriptions for each table, field, and index and replaced the old, hard-coded
Reindex routine with Stonefield's data-driven Reindex screen. Then, with a push button and four
lines of code per screen, I added AppMaker's generic incremental search functionality to several
existing data-entry screens. For grins, here's the necessary code:
IF BROWSER()
SCATTER MEMVAR MEMO
SHOW GETS
ENDIF
Because BROWSER automatically takes care of opening the data-dictionary files (and closes
them again unless they were already open), the simple syntax is all that is needed to add a great
AppMaker feature into a legacy system. The users loved it.
Part of the reason that it's easy to use AppMaker routines in a non-AppMaker application is the
way in which those routines are documented internally. Each routine contains a section of
comments titled "Environment In" that takes the guesswork out of which variables need to be
defined, which tables need to be open, which index order they should be in, and so forth.
Similarly, the "Environment Out" section of each routine's comments provides information about

what to expect after your program has called the routine.
Documentation
If you read the review of Stonefield Data Dictionary in the February 1996 FoxTalk, you're in for
déjà vu. The documentation for Stonefield AppMaker is every bit as good as SDD's. The
100-plus page (including an index) manual provides everything you need to learn how to use
AppMaker. In addition, the documentation contains an appendix that explains how AppMaker
uses GENSCRNX to generate screens that are aware of the information stored in your data
dictionary.
But the documentation doesn't stop with the manual. The product comes with full source code
that's superbly commented. The requirements for using every routine are specified in a consistent
program header that includes descriptions of any parameters and whether each is required or
optional. In fact, the program documentation is so good that you'll probably find little need for
the printed manual after having used the product long enough.
When you install AppMaker, it creates a SAMPLE subdirectory that contains a complete sample
application that was generated with AppMaker. You may find that running and examining the
sample application is one of the best ways to quickly learn about AppMaker features.
Technical support
Technical support for Stonefield products also is superb. It's available via CompuServe, fax, and
telephone. Following the trend set by many other vendors, Stonefield recently instituted a charge
policy for telephone support. Priority support is available for $199 per year. This plan, which is
free for the first 60 days, includes version updates and allows you to contact Stonefield by
telephone, fax, or CompuServe. Standard support is free and is provided via CompuServe only.
Standard support customers must pay for version updates (typically $99).
When a bug is reported, it's fixed immediately and the fix is sent to the person who reported it. If
it's a serious bug (one that could cause data loss, for example), an update is sent at no charge to
all registered users. If the bug is minor or occurs only under unusual circumstances, it and other
bug fixes are sent out periodically as a "maintenance release," which also is at no charge.
In my experience, support has been excellent both over the phone and via CompuServe. Phone
calls are answered or returned quickly, and CompuServe messages usually receive responses
within 24 hours (often much more quickly than that). When I've reported bugs, the fix has
always been delivered to me via CompuServe within 48 hours. Occasionally, enhancement
requests have been handled in the same way.
Pricing for AppMaker and other Stonefield products
The cross-platform (DOS and Windows) version of Stonefield AppMaker is $249 (U.S). The
product includes Stonefield Data Dictionary and Stonefield Reports. Developers who already
own SDD can purchase just the combined AppMaker/Reports product for $149. SDD can be
purchased separately for $99. Each comes with royalty-free source code and a 60-day
unconditional money back guarantee. One copy is required per developer; multi-developer

licensing is available.
Stonefield Reports (DOS and Windows, $99; no Mac version yet) is an end-user report manager.
It allows users to select and print reports through an easy-to-use user interface. Its "quick report"
function allows a user to quickly create a report by simply selecting which fields to output.
Stonefield Database Toolkit for Visual FoxPro ($249 or upgrade from SDD for $149) extends
the VFP database container to provide the features of Stonefield Data Dictionary. These features
include the ability to define extended properties for tables, fields, and index tags as well as a
class library of methods that you may use to add data management functions to your
applications.
For more information, contact Stonefield Systems Group by accessing their Web site (), sending
CompuServe e-mail to 75156,2326, calling them at 800-563-1119 (306-586-3341 outside the
United States and Canada), or by sending a fax to 306-586-5080.
The bottom line
If you already have a strong library of reusable routines and a method for quickly creating the
screens and other components of your applications, then you may not need Stonefield
AppMaker. But, if you're like most developers I know, you probably can't go wrong by investing
the income from a few of your billable hours to receive the source code that has resulted from
years of experience and several hundreds of development, testing, and documenting hours.
Kelly Conway is an in-house software developer with Dimoco Manufacturing Company in Lee's Summit,
Missouri. In the last eight years, he has developed FoxPro application for numerous clients in the Kansas
City area. Kelly also is a co-founder and past president of The Midwest Fox Pros -- a FoxPro user group
that serves more than 100 members from throughout the heartland.
Create DBF-Style Help with HELPX, a
GENSCRNX Driver
Jeff B. Baker
Creating an online Help system is usually the last part of the development process, like avoiding the
dentist until the last possible moment. HELPX, a GENSCRNX driver, allows you to quickly and
easily add DBF style Help to any screen in current or existing projects.
You've just spent the last six months building the ultimate application for a client. The result far
exceeds their expectations. The client asks when it can be installed. You hesitate for a moment
(5)

then you say that it'll be another two months because you still need to write the Help system!
Writing a Help system can be about as much fun as having wisdom teeth pulled.
Most of my applications consist of data entry screens hanging off menus or called from other
screens. Consequently, a large portion of the Help file will consist of topics associated with
screen objects. Doesn't it make sense to add your Help directly into the screen through the
Screen Builder as you're creating and adding the objects similar to commenting source code as
you're writing it?
HELPX, a GENSCRNX Help driver
I took advantage of Ken Levy's GENSCRNX to create a simple but time saving solution for
creating Help tables. In my opinion, the best feature of GENSCRNX is being able to write your
own driver that "hooks" into GENSCRNX during screen generation. A GENSCRNX driver is
perfect for generating DBF-style Help directly from your screens.
HELPX allows you to add Help to the Comment field for any object on a screen. The generated
DBF-style Help table is identical to FoxPro's own Help table. The topic is surrounded by a single
line box, a summary for the topic can be added below the topic, the main text of the Help can be
followed by an example, and one or more See Also topics can be included. All of this is
accomplished by adding the appropriate HELPX screen directives in the Comment fields of
screen objects.
Help table structure
The basic structure of a DBF-style Help table consists of three fields: Topic, Details, and Class.
Topic contains a short topic description. Details is a memo field in which all information about
the topic is placed, including the summary, examples, and see also topics. The Class field can
contain any characters up to a total of 20. It can be used to filter out certain Help topics.
As long as the three basic fields are included in a Help table, other fields may be added to
incorporate additional features for a custom Help system. HELPX uses the three basic fields plus
one additional field to Help during the Help table creation.
HELPX directives
To enable the HELPX driver, add the following command to each platform's CONFIG file:
_SCXDRV5=helpx.prg
This will automatically create Help for the current application's screens when the project is
rebuilt.
HELPX incorporates nine simple directives for the actual Help text. Add *:ADDHELP to the
setup code snippet for every screen in which you wish to add Help. Add one or more of the
following directives to the comment field for each object you want included in the Help table, .

The only required comment directive is *:HELPTOPIC. A Help record won't be created if the
topic directive is missing.
You'll need to take a few considerations into account. The text associated with the summary,
main Help text, and example directives must start on the line following the directive. Any text on
the same line as the directive will be ignored. New paragraphs in each of these sections can be
created by pressing the enter key to move to the next line. MEMOWIDTH is set to 256, but you
should limit the width of any one line to the Help window size depending up which platform
you're using; otherwise, you may run into strange looking results. Table 1 contains the directives
you can use.
Table 1. Help text directives and their purposes.
*:HELPTOPIC Defines the topic for the current object.
*:HELPDESCSTART Defines the beginning of a summary section,
whichmust start on the next line.
*:HELPDESCEND Defines the ending of a summary section.
*:HELPTXTSTART Defines the beginning of the main Help text,
whichmust start on the next line.
*:HELPTXTEND Defines the ending of the main Help text.
*:HELPEXSTART Defines the beginning of the example text, which
muststart on the next line.
*:HELPEXEND Defines the ending of the example text.
*:HELPSEEALSO A comma delimited list of See Also topics.
*:HELPCLASS The class or classes for the Help topic, which arespace
delimited.
The following is an example of Help being added to a comment field. The topic, summary, Help
text, see also, and class are shown:
*:HELPTOPIC Client Name
*:HELPDESCSTART
The client name field contains the first and
last name of the client.
*:HELPDESCEND
*:HELPTXTSTART
This would be the main section of Help for the
client name. If you wish to start a new line
without word wrapping, press ENTER at the end
of the line instead of letting the line wrap.
Here could be the second paragraph of the main Help text:
*:HELPTXTEND
*:HELPSEEALSO CLIENT ID, ADDRESS, PHONE
*:HELPCLASS General Client

If you already have an existing DBF-style Help table based upon the FoxPro Help structure for
the rest of your application, append HELPX.DBF to incorporate your screen Help
HELPER, a HELPX helper application
A helper utility has been included to make adding Help directives and text to comment fields
easier. It isn't required for HELPX, but it can make your life easier when developing a screen
and adding Help.
The Helper utility uses another great GENSCRNX driver, TABS, written by Steven Black.
Helper consists of one screen with five tabs. The five tabs are Topic, where the topic and class
are entered, Summary, Help, Example, and See Also (see Figure 1 and Figure 2). Open one of
your screens and select the desired comment field of an object.
Helper is designed to use the right mouse button to call it with an ON KEY LABEL in DOS,
UNIX, or Windows. Ctrl-Z is used on the Mac since the Mac doesn't have a right mouse button.
This key combination can be changed to whatever you desire.
Once Helper has been brought up, enter only the information that will actually appear in the
Help file, not the directives. Once all desired information has been entered, click on the Copy to
Clipboard button and then Cancel. Then in the comment field, paste from the Clipboard by
Ctrl-V. That's it! Directives and associated Help text will be placed in the comment field.
Conclusion
HELPX can't entirely automate your Help system, only the Help for your screens. All other Help
must still be entered by hand. Since data entry applications tend to be screen oriented, you'll still
save a considerable amount of time by using HELPX to create your Help files. If you have a
custom Help table with additional fields, HELPX can be modified easily to incorporate new
directives. HELPX takes what once might have been a chore, creating Help, and turned it into
another indispensable tool.
Jeff Baker is a FoxPro software engineer for Lifo Systems Inc., the nation's largest LIFO consulting and
computation company serving more than 4,000 businesses and CPAs nationwide. When not
programming, he can launches model rockets and flies stunt kites. jbb@airmail.net.
Access the Clipboard Functions; Using a
Form Handler
John V. Petersen

I have an application in version 2.6a. In order to conserve screen space, I set SYSMENU
OFF. Now I can't access the Clipboard functions of Cut, Copy, and Paste. Is there a way I
can have access to these important functions without having the system menu present?
Randy Strouth
When the system menu is turned off, you lose access to any shortcut keys defined both by the
menu and any pop-up definitions that currently reside in memory. This includes the standard
Windows Clipboard functions you're attempting to use in your application. The key, then, is to
not have access to the menu and at the same time, reclaim the screen real estate. SET
SYSMENU TO won't work. Although you can't access the menu, the screen real estate isn't
reclaimed. Enter this FoxPro command that some of us have forgotten: HIDE MENU.
The system menu that contains the Windows Clipboard functions is called _MEDIT. At the top
of the main program of your application, place the following code:
HIDE MENU _msysmenu
SET SYSMENU TO _medit
While the second line of code isn't necessary, it takes care of releasing the additional system
menus that aren't required.
If you want to have the system menu suppressed when FoxPro starts, add this line to your
configuration file:
SYSMENU = OFF
Now you get the best of everything. The reclaimed real estate, no menu, and access to the
Windows Clipboard shortcuts in your application.
What's the purpose of a form handler? They seem to be associated with most,
if not all, available application frameworks. Isn't the Forms Collection
associated with _SCREEN a native form handler? If it is, aren't we just
re-inventing the wheel?
Name withheld by request
The basic purpose of a form handler is just that, it's an object whose sole purpose is to manage
your form instances. While the _SCREEN object possesses a Forms Collection, it's by no means
a form handler. Rather, the Forms Collection is an array of object references of currently
instantiated forms and toolbars. Here enters the first limitation of relying on the forms collection
to refer to forms. Toolbar objects are mixed in with form objects. A property of SCREEN,
FormCount, counts both toolbar and form objects. For example, if you have a form and a toolbar
instantiated, what's the value of _SCREEN.FormCount? The answer is 2! That probably isn't

what you expected. More importantly, your code might not expect this and in turn may break.
Let's move on . . .
What if you wanted to act on the group of forms as a whole? For example, what if you wanted to
release your forms simultaneously and at the same time ensure that it's okay to release the form.
After all, you may have uncommitted buffers in some of your forms. Also, what if you wanted to
limit the number of instances of a forms that can be active at one time? In my February 1996
column I suggested a way to utilize the Forms Collection to limit the number of instances. While
this method will work, a custom form handler class is the way to go. Now, let's answer why this
is so.
When we create our own classes, we have the ability to exert the maximum amount of control
and enjoy a great deal of flexibility in a situation. I say control because we have the ability to
interject our own rules. I say flexibility because we can act on the group of forms as a whole.
Lets look at a simple form handler class:

DEFINE CLASS cForms AS custom
DIMENSION iaInstances[1,3]
inForms = 0
ioForm = .NULL.
PROCEDURE Error
LPARAMETERS nError, cMethod, nLine
LOCAL lcMessage
LOCAL ARRAY laError[1]
=AERROR(laError)
lcMessage = "The following error has occurred: " ;
+ CHR(13) + CHR(10) + ;
laError[2] + CHR(13) + CHR(10) + ;
"Method: " + cMethod + CHR(13) + CHR(10) + ;
"Line Number: "+ ALLTRIM(STR(nLine))
=MESSAGEBOX(lcMessage,16,"An error has occurred")
RETURN
ENDPROC
PROCEDURE Release
RELEASE THIS
ENDPROC
PROCEDURE HowManyInstances
LPARAMETERS tcClass
LOCAL lnRetVal,lx
lnRetVal = 0
tcClass = UPPER(tcClass)
FOR lx = 1 TO ALEN(THIS.iaInstances,1)
IF !ISNULL(THIS.iaInstances[lx,1])
llRetVal = THIS.iaInstances[lx,1].QueryUnload()
IF UPPER(THIS.iaInstances[lx,1].Class) = ;
tcClass
lnRetVal = lnRetVal + 1
ENDIF
ENDIF
ENDFOR
RETURN lnRetVal
ENDPROC
PROCEDURE DoForm
LPARAMETERS tcForm
LOCAL lcID
lcID = SYS(2015)
THIS.inForms = THIS.inForms + 1
DIMENSION THIS.iaInstances[THIS.inForms,3]
IF FILE(tcForm+".SCX")
DO FORM (tcForm) NAME THIS.iaInstances[THIS.inForms,1] LINKED
ELSE
THIS.IaInstances[THIS.inForms,1] = ;
CREATEOBJECT(tcForm)
THIS.IaInstances[THIS.inForms,1].Show()
ENDIF
WITH THIS
.iaInstances[ THIS.inForms,1].Comment = lcID
.iaInstances[THIS.inForms,2] = lcID
i I t [ THIS i F 3]

Now I have some element of control. I can ask my form handler both questions about the forms
that it manages and to delegate tasks to the forms as well. The following code takes care of
running a form stored as an SCX:
oForms.DoForm("myForm")
The following code takes care of running a form stored as a class:
oForms.DoForm("myFormClass")
As you can see, I've provided a common interface via the DoForm method. The details of how
the form is stored, (.SCX vs .VCX) are hidden from me. If I chose to cascade the forms, the
following code will do the trick:
oForms.Cascade()
If I chose to poll all of my forms to see if it's okay to close down the application, I can issue the
following code:
IF oForms.QueryUnload()
**code to shut down app
ELSE
**continue with app open
ENDIF
If I want to know how many of each class of form is instantiated, I just ask this question:
? oForms.HowManyInstances("myformclass")
At this point, it should be fairly obvious how beneficial and labor saving a
forms handler can be.
John V. Petersen, MBA, is director of FoxPro and Visual FoxPro development and training for Pearl
Computer Systems Inc., a Microsoft Solution Provider and authorized SBT Reseller based in Mount
Laurel, New Jersey (609-983-9265). John is active in the FoxPro community, has written for publications
in the United States, and has been a speaker at user group meetings and at the 1995 Developer Days
Conference. 103360.1031@compuserve.com.

Sidebar: Correction
In my column in the March 1996 issue, I answered a question about refreshing the contents of a
ListBox Control that is based on a view (the RowSourceType Property is set to Alias). In that
response, my suggestion was to set the RowSource = RowSource and then to subsequently call
the Refresh() Method of the ListBox Control. While this solution works, it's less than optimal.
Once you've called the REQUERY() function on a view, all you need to do to refresh the
contents of a ListBox or ComboBox is call the Requery() method of the control. -- J.P.
Tip: Refreshing Page Frames from Hot Key
Activations
Mark Nadig
I've run into a situation when using William O'Connor's idea for refreshing a page (Fast and
Furious Pageframes, FoxTalk, May 1996). His refresh code assumes that the user will click on
the desired page, but it's possible to set up a hot key for the page tab. In this case, the refresh
code won't execute.
Add the following code to handle this situation:
PageFrame Init()
LOCAL nPage
FOR m.nPage = 1 TO This.PageCount
This.Pages[ m.nPage].AddObject( "txtPageFix", ;
"Wind2PageFix")
ENDFOR
RETURN
Create the following class and add it to every page in a pageframe:

DEFINE CLASS Wind2PageFix AS TextBox
Enabled = .F.
TabStop = .F.
Visible = .F.
Width = 0
Height = 0
PROCEDURE UIEnable
LPARAMETERS lEnable
* This object is created for every
* page in a pageframe.
* The purpose is to handle pages not refreshing.
IF m.lEnable
LOCAL lOldLock
m.lOldLock = Thisform.LockScreen
Thisform.LockScreen = .T.
This.Parent.Refresh()
Thisform.LockScreen = m.lOldLock
ENDIF
RETURN
ENDPROC
ENDDEFINE
The UIEnable method of the text box will fire on both page activation and deactivation. You
need to refresh only on activate.
Mark A. Nadig is product development technical manager at Wind2 Software Inc., a Fort Collins,
Colorado publisher of accounting and business management software. 970-482-7145. CompuServe
74250,1500.
Modify Objects with ObjectExplorer
Markus Egger (6)
The ObjectExplorer is a tool that allows you to explore and modify objects in Visual FoxPro
memory. Written by Markus Egger, the author of GenRepoX, ObjectExplorer is freeware and
requires some basic know-how about the VFP object model. However, it's useful during
development and is a great tool for delving deeper into VFP.
The ObjectExplorer presents an outline view of all objects that have been instantiated in Visual
FoxPro memory. The top level object is the "_screen" object -- the VFP screen that always exists
and may or may not contain additional objects. Each property, event, and method of an object is
represented by a ball icon; each object contained within the higher level object is represented by
a closed book icon. Double-clicking on the closed book icon will change the icon to an open
book and display a tree of that object's properties, events, and methods in outliner form.
In Figure 1, the ObjectExplorer form shows the _screen object, the SuperClass object that has

een instantiated (see FoxTalk, January 1996 "Cool Tool: Ease Form Design Tasks with
SUPERCLASS", for a description of SuperClass), and the ObjectExplorer object itself. As you
can see, the properties, events, and methods for the _screen object are all listed, together with
their value in the case of properties. You can switch between objects easily by using the
drop-down combo box on the top of the form.
This is an easy way to explore the structure of objects, since they can become very complex and
details are easy to overlook. But besides that, this tool hasn't been very useful so far. Explore the
_screen object again and look for the Closeable property. Now double-click this property and
you'll see that the value of this property changed from .T. to .F. And if you watch the screen
itself, you see that this property changed in real life too -- in Windows 95, for example, the Close
box in the upper right corner of your screen has been dimmed. Now look for the caption
property, double-click it, and you'll get the Insert a New Property dialog box as shown in Figure
2.
That's neat, but is it really useful? Yes it is. I'll show you some more functionality, and you'll see
why. Look for the SaveAsClass method and double-click it to get the Fire an Event/Method
dialog box as shown in Figure 3.
You may have expected that double-clicking on a method or event would just execute it. Why
didn't it? Sometimes you need to define parameters for your methods. In our example, the
original value was _screen.SaveasClass(). We change this to
_screen.SaveasClass("screen","screen"). Click OK, and the ObjectExplorer creates a classlib
called screen and stores a class called screen in it. This class is a subclass of our Visual FoxPro
screen. You can now edit this class with the visual class designer.
OK, this is already very nice, but there's more. Open the Visual FoxPro class browser. Make the
class browser the active form. Now click Refresh in the toolbar of the ObjectExplorer, but don't
make the ObjectExplorer the active form (in other words, don't activate the ObjectExplorer
window). It takes the ObjectExplorer a little while to be updated, since there are lots of objects in
memory. After a few seconds, the ObjectExplorer comes up and shows the screen-object again.
But remember that the class browser was the active form when the ObjectExplorer was updated.
So expand the screen object and expand the ActiveForm object. Voilà! Here's our class browser,
and we didn't even know how the class browser was called. You can now explore and modify the
browser and, guess what, you can even save it as a class.
We've already seen from the class browser example that there can be lots of items in the tree
view, so let's look for ways to customize the ObjectExplorer. We can do this using the Explorer
ToolBar as shown in Figure 4.
As a default, this language is English but you can also change it to German, Portuguese, Spanish,
French, and some others.
The next five controls allow you to change the font and fontstyle in the Explorer window. You
can also switch between a tree view and a +/- view. All these controls deal more with cosmetics
than real functionality, but the next one is very important. It's the refresh button, which is used to
update the information displayed in the Explorer window. You may be wondering why I didn't

integrate this button in the Explorer window itself. You couldn't use the ActiveForm property of
the _Screen object, since the Explorer itself would always be the active form if the button would
be on this form. But toolbars never become an active form, so the topmost window will show up
as the active form in the Explorer window.
The next two buttons are very useful if you want to customize the Explorer. The M button
determines whether you want to see methods and events as well, or only properties. The default
is for this button to be pressed meaning that all events and methods are displayed as well. The
next button defines whether you want to see all properties, or only the ones with non-default
values. This feature is only available in Visual FoxPro Version 3.0b or higher. By default this
button isn't pressed, which means that all properties are displayed. You must refresh the Explorer
window after pressing one of these buttons for the effects to take place.
The next button, the Builder, works a lot like the builder button in the property sheet of the class
and form designer. If you press this button, the ObjectExplorer searches an edited object in
memory. This could be an object that is actually modified with the class or the form designer. If
there is one, the whole structure of this object is displayed in the Explorer window. The only
difference between a real life object (one that is actually running) and a builder object are the
way events and methods are handled. When you explore a builder object, you can edit the code
related to those events and methods instead of firing them.
As you dig deeper into this complex tool called Visual FoxPro, you'll find that the tools you have
to work with it haven't quite caught up. I hope you find the ObjectExplorer useful as one of a
new line of developer tools for Visual FoxPro.
Markus Egger has been involved in the computer business for more than 10 years. Markus owns the
European software house EPS-Software and is involved in the American company MTI-Software. He
works with Visual FoxPro and Visual C++, and is an international speaker and author.
100337.1062@compuserve.com.
Why Are You Here?
Les Pinter
[The following is based on introductory remarks by Les Pinter at the June 1996 Microsoft
Developer's Conference in Obninsk, Russia. -- Ed.]
Five years ago at the International Computer Conference in Moscow, a brash a young Russian
programmer named Mikhail Korneev sat down beside me and abruptly said "So why are you
here?" I didn't have a good answer, but I thought about it for a long time, and I'd like to answer
it now. (Mike gets FoxTalk, so he'll be reading this as you read it. Privyet, Misha.)
Forty years ago, as I sat in a classroom in Fairbanks, Texas, with 30 or so other Texas fourth
graders, a car drove by our school and the light reflecting off the windshield flashed through our

window. We all dove under our desks because we thought it was the end of the world.
This happened because 40 years earlier, just prior to the Russian Revolution, the situation in
Russia was desperate. Lenin and his colleagues were saying to each other, "If we don't help each
other, we won't have a future." Unfortunately, as we now know, things went from bad to worse
and the result was the Cold War. That's why a classroom full of children all jumped under their
desks when a bright light flashed through the window in Texas in 1956.
Ten years ago Mikhail Gorbachev changed the world. As a result we now know that the
government in Russia can't help us. So we have to help ourselves -- and each other.
Eight years ago, I was desperate to find some clients for my new database consulting company in
California. So I started a FoxPro newsletter and business got better. I came to understand that
people really depended on my articles; they used them to get their work done and get paid. So by
helping others, I helped myself. Eventually I wrote six books about FoxPro and things got a lot
better.
FoxPro is the single best opportunity for independent programmers in Russia to build a business.
The need for database applications is huge and will grow even larger as people realize the power
of information in business, and as the cost of clerical employees rises. It doesn't require a college
degree; anyone who can read can build a business. In the process, programmers help themselves
and they help Russia turn its back on the past. And regardless of what you hear (or don't hear)
from Microsoft marketing people, FoxPro beats the pants off VB and Access. Introducing young
Russian programmers to FoxPro and helping them get up to speed is the only thing I can think of
to fend off the resurgence of the bad old days. It's important.
Six years ago I received an article submission from a young Russian programmer with a Moscow
phone number at the bottom of the page. I looked at that letter for several weeks, and finally
decided to give the guy a call. The eventual result was that we began to publish a Russian edition
of my newsletter. Today that same young man works for Microsoft, makes a good living, and
travels all over the world. And the Pinter FoxPro Letter has more than a thousand Russian
subscribers who depend on it to help them earn a living -- a decent, honest living. Over half of
them are independent contractors, the finest of Russia's honest self-employed. They show
Russians that you don't have to be a criminal to make a good living.
Last year I began to organize groups of programmers in Moscow and Ukraine to do work for my
American clients. We send specifications by Internet and our programmers return the finished
programs. We now have four groups of FoxPro developers who live in Russia and Ukraine but
work in America. They earn a good living, and eventually most of them will fly over and meet
their clients on the way to Disneyland or Maui. Then they'll go home and tell their colleagues
what the market economy is all about. Perhaps it seems like a small thing, but show me what the
American government has done to help my friends on the other side of the world. And it's indeed
a small world.
Why am I here? I'm here because I made that telephone call. I'm here because there are in this
very room several programmers who have a better job, and a better future, because we took a
risk. I'm here because I think perhaps Lenin was right: If we don't help each other, we won't have

a future.
Les Pinter publishes the Pinter FoxPro Letter in the United States and Russia. 916-582-0595.
SQL and Readable Code
Barbara Peisch
Steps to Help Debug Your SQL
If you've written a long SQL SELECT statement only to have FoxPro return an error, you know
how frustrating it can be to find the location of the problem. Track down the error by breaking
up your code and trying each part.
Start by running just the code that select fields and specifies the tables the data is coming from.
Make sure you include any join conditions necessary in your WHERE clause, but don't include
any filter conditions. (An example of a join is WHERE Parent.Invoice = Child.Invoice. An
example of a filter is WHERE InvDate BETWEEN Date1 and Date2.) If you have an error in
that part, try eliminating the fields one by one until the problem disappears. If you suspect the
problem might be with one of the join conditions in your WHERE clause, eliminate all the fields
that rely on that join and remove the condition from the WHERE clause to confirm or disprove
your suspicion.
If you can run the select with all your fields and joins, add in any filter expressions you had in
your WHERE clause.
If you have a UNION, try running each select within the UNION separately to see which one has
the problem.
If you have several UNIONs and each of your selects runs independently, try running the first
two. If that works, keep adding one more until the error reappears.
Sometimes the problem isn't with the specific code you used, but where it occurs. If you can, try
switching the order of parts of your select to see if the problem occurs on the same code or if it
occurs in the same position.
. . . And on Another Note
If you use a lot of command button groups in your 2.x applications, you know how easy it is to
forget what order the buttons are in when trying to write code to enable or disable specific
buttons. You might have something like this in your SHOW clause:

DO CASE
CASE
SHOW GET , 1 DISABLE
SHOW GET , 2 ENABLE
SHOW GET , 3 DISABLE
CASE
SHOW GET , 1 ENABLE
SHOW GET , 2 DISABLE
SHOW GET , 3 DISABLE
OTHERWISE
SHOW GET