Lessons
Learned
in Version
Control,
Part 2
Doug Hennig
The previous article, the first in this three-part
series, looked at setting up local and remote reposi-
tories and how to deal with files commonly used in
multiple applications. This time, we’ll look at how
to handle VFP binary files and what should go in
the repository, then discuss the workflow we use at
Stonefield Software.
Dealing with VFP binary files
In the last article, we set up version control for a
new application, creating local repositories on two
machines (one named Doug and the other named
Peggy) and a central repository on a file server,
Now we’re ready to start working on the applica-
tion. We need to add buttons to the form and code
in the Click method of those buttons. However, if
we both work on the same form, we’ll have a big
issue: how to consolidate our changes?
As I’m sure you’re aware, some VFP files are
actually tables: VCX, SCX, PJX, MNX, FRX, LBX,
and DBC (along with their accompanying memo
files). Since VFP tables are binary files, they can’t
March 2017
Number 55
1 Deep Dive
Lessons Learned in Version Control,
Part 2
Doug Hennig
6 VFP
Seamlessly Read/Edit/Save numeric
data of variable precision
Pradip Acharya
8 VFPX
Continuous Integration with
Jenkins and Visual FoxPro
Eric Selje
19 VFP
With abbreviations to success
Christof Wollenhaupt
be compared to each other using traditional “diff”
tools. As a result, you can’t compare changes in two
copies of a file, nor can you merge changes.
Fortunately, there are several tools available
that convert VFP binary files to text files that can
be compared and merged. The latest one is FoxBin-
2Prg, a VFPX project. There’s even an extension for
it, Bin 2 Text Extension, also a VFPX project, which
adds support for Git and IDE integration.
Installing FoxBin2Prg is easy: simply download
it from VFPX (http://vfpx.codeplex.com) and install it
in any folder. If you use Thor (the most important
add-on there is for VFP and also a VFPX project),
it’s even easier: from the Thor menu, choose Check
for Updates, turn on FoxBin2Prg in the dialog that
appears, and click Install Updates. I’m going to
assume you’re using Thor for the purposes of this
article. If not, see the FoxBin2Prg documentation
for instructions on how to use it.
To create text versions of all of the binary files
in a project, choose Thor Tools, Applications, Fox-
Bin2Prg, Projects, Convert All Binary Files to Text
Files from the VFP system menu. This function cre-
ates text files from the binary files, using the same
file name as the binary files but with “2” replacing
the final “x” in the extension (for example, MyApp.
pj2 for the text version of the PJX file). A similar
function does the opposite: generating binary files
from the text files. To make it easier to access the
functions, you can create a Thor hotkey for that
using the Thor Configuration dialog. I use Alt-1 to
create text files from the binary files and Alt-2 to
create binary files from the text files.
I created a little Thor tool that both creates text
versions of all binary files in a project and brings up
the TortoiseHg Commit dialog, saving a few mouse
clicks. I assigned a hotkey of Alt-3 to the tool so
when I’m ready to commit changes in the applica-
tion, I simply hit Alt-3, enter a comment, and click
Commit. Creating a Thor tool is beyond the scope Figure 1. The Resolve Conflicts dialog shows which files have
of this article, but all it really does is: conflicting changes that need to be resolved.

do (_screen.cThorFolder + ;
'Tools\Thor_Tool_Repository_' + ;
'FoxBin2PrgConvertProjectToText.prg')
run /n0 thg commit
Thor_Tool_Repository_FoxBin2PrgConvert-
ProjectToText.prg is the Thor tool FoxBin2PRG
installs to convert the binary files in a project to text
files.
To add my tool to Thor, simply copy Thor_
Tool_Convert2PRGAndCommit.prg (included
in the downloads for this article) to the Thor\
Tools\My Tools folder of wherever you have Thor
installed. Choose Configure from the Thor menu
and assign a hotkey to this tool if you wish.
It’s important to generate text files for the bina-
ries in the project, add them to version control,
push them to the central repository, and pull them
into all developers’ repositories only when all other
changes have been synchronized in all repositories.
Otherwise, merging the changes can be a mess.
To see this in action, I generate text files for the
binaries in the project, add them to the repository,
and push to the server; Peggy pulls from the server
and updates so she has the latest version. Then I
modify the code in the Click method of the existing
button in the form while Peggy adds another but-
ton to the same form. I commit and push, then she
commits, pulls, and merges with her local changes.
Because we both made changes in the same form,
there are several merge conflicts that need to be
resolved (Figure 1). Tool Resolve handles the differ-
ences in MainForm.sc2 but it can’t resolve the dif-
ferences in MainForm.scx and sct because they’re
binary files. In this case, it doesn’t matter whether
we choose Take Local or Take Other since we’re
going to regenerate the two files from MainForm.
sc2 in a moment.
After the update, Peggy uses the hotkey she
assigned to generate binary files from the text files.
When she then edits MainForm.scx, she sees both
of our changes.
One of the things you’ll note is that when I
open the project, I’m prompted to change the home
directory. After I push changes and Peggy pulls
them, she’s prompted to change the home direc-
tory when she opens the project. This gets a little
annoying after a while, so we’ll see how to resolve
this next.
What should go in the
repository?
If you look at the list of files in the repository, you’ll
notice I added everything in the project folder hier-
archy, including FXP and EXE files. Is that neces-
sary or desirable? Not really:
• The larger the repository, the longer it
takes to clone, commit, push, pull, etc.
• Even if you don’t change the source
code, rebuilding a project may regener-
ate FXP and other generated files. As a
result, it looks like you have to commit
and push and other developers have to
pull and merge even though nothing’s
really changed.

Page 2 FoxRockX March 2017

 The general rule of thumb is that nothing gen-
erated should go in the repository. In the case of a
VFP application, that means you should exclude:
• EXE, APP, and DLL files generated by
your projects
• FXP, MPX, and QPX compiled program
files
• MPR files since they’re generated from
menus
• ERR, BAK, and TBK files
• Any files generated by running your
application (TXT, HTML, XML, MEM,
etc.)
Other files require some consideration.
• VFP binary files: assuming you’re using
FoxBin2Prg or something similar as dis-
cussed in the previous section, you can
exclude the binary files. One benefit of
this is that you’re no longer prompted to
change the home directory for the project
when you open it, since you’re recreating
it with the current directory when you
use FoxBin2PRG to generate the binary
files.
• Data files: it depends: if they’re used but
not maintained by the application—for
example, meta data such as Stonefield
Database Toolkit’s, lookup data, con-
figuration settings not maintained by
the user, etc.—definitely (don’t forget to
include any CDX or FPT files in addition
to the DBF). Otherwise, probably not,
or else every time you add a record to
a sample copy of the tables maintained
by the application, they’re marked as
changed and have to be committed,
pushed, pulled, merged, etc. Database
container files (DBC, DCX, and DCT)
should be included unless you use GEN-
DBC to generate a program to recreate
the database; in that case, include that
generated program. You might want to
use FoxBin2Prg to convert tables and
database containers to text files and
include those instead. FoxBin2PRG
doesn’t handle data files automatically;
see its documentation for details on how
to configure it to do so.
• Images: these should be included but
keep in mind that they’re binary files so
changes made by more than one person
at a time can’t be merged. Fortunately,
most developers I know get their images
from other sources rather than creating
them themselves so this is rarely an issue.
• CHM (help) file: there’s no need to
include the CHM file (or CHW file if it
exists) since it can be regenerated from
March 2017 FoxRockX
whatever source you used to create it.
If you’re using West Wind HTML Help
Builder, you should include the HBP,
FPT, and CDX files for the help source
as well as WWHelp.ini and the contents
of the BMP, Images, and Templates fold-
ers (you can actually skip the BMP and
Templates folders since they’re created
when you create a new help project and
don’t change, but I include them to make
it easier to clone the repository). The
rest of the files are generated by Help
Builder and so should be excluded. Note
that since the HBP file is actually a VFP
table, you might want to use FoxBin2Prg
to convert it to a text file and include the
text file instead.
• Testing files: this includes FoxUnit or
other test programs, any configuration
settings, and test data. These should be
included in the repository. As with the
other points, consider using FoxBin2Prg
to create text files from any binary files
and include those instead.
• Documentation: this could be Microsoft
Word documents describing the feature
set, Microsoft Excel documents detailing
the development plans and costs, and
so on. Note that these are binary files so
you won’t be able to merge changes. For
that reason, it’s best if only one person be
responsible for editing these files.
• Deployment files: your setup source files
(for example, the ISS file if you use Inno
Setup) as well as any other files related to
deployment (such as BAT or PowerShell
PS1 files) should be included.
• Visual Studio files: if you’re like me and
have some in-house .NET components
in your applications, you should include
the source files for those components in
the repository. You can exclude the gen-
erated files (those in the BIN and OBJ
folders) and SUO (user preference set-
tings) file.
• hgignore or gitignore file: these files con-
tain information about which files the
version control system should ignore.
They should be included in the reposi-
tory even though they’re not strictly part
of the project.
Ignore file
Speaking of the ignore file, you should use one to
tell your version control software not to list cer-
tain files in the commit dialog. Otherwise, it’s dif-
ficult to tell which are files you routinely exclude
and which are new but haven’t been added yet.
Page 3
See http://tinyurl.com/hpgh8yy for a discussion of # Folders to exclude
bin/*
­.hgignore for Mercurial. Listing 1 has the content obj/*
of a typical .hgignore file for a VFP application (this
file is included with the downloads for this article). # Specific files
Note that .hgignore is case-sensitive so file name *.exe
*.EXE
and extensions are usually listed in multiple cases
unless you use regular expression syntax. You can also set up a global ignore file, one
Listing 1. Typical .hgignore file for a VFP application. that’s used for every repository, by editing your
# use glob syntax. global settings file (usually C:\Users \UserName\
syntax: glob Documents\Mercurial.ini, where UserName is the
Windows user name) and adding the following to
# VFP generated files
*.err
the [ui] section:
*.ERR [ui]
*.qpr ignore = Path
*.QPR
*.mpr In place of Path, put the desired path and file
*.MPR
name. For example, if you specify “%USERPRO-
# VFP compiled files FILE%\.hgignore,” Mercurial uses .hgignore in
*.fxp your Documents folder.
*.FXP
*.mpx After setting up the ignore file, remove the files
*.MPX you no longer want under version control by select-
*.qpx ing them, right-clicking, choosing TortoiseHg, and
*.QPX
Forget Files, then commit the changes. Note: one
# VFP backup files issue you might run into when you do this is that
*.bak the case of the file extension somehow changes.
*.BAK For example, I removed “mainform.sct” from the
*.tbk
repository but when I went to commit the change, it
*.TBK
failed because “mainform.SCT” wasn’t part of the
# VFP binary files repository. To fix this, I reverted the change to the
*.pjx file (which now has an SCT rather than sct exten-
*.PJX
sion), then forgot the file again and committed the
*.pjt
*.PJT change.
*.vcx
*.VCX
*.vct Workflow
*.VCT Here’s the process for development to ensure all
*.scx
developers keep updated with other developers’
*.SCX
*.sct changes (see Figure 2):
*.SCT • Make changes as necessary.
*.mnx
*.MNX • Run any tests you have for the project
*.mnt and fix any problems identified by fail-
*.MNT ing tests.
*.frx
*.FRX
• Convert the binary files to text files.
*.frt • Commit the changes.
*.FRT • Pull from the central repository to
*.lbx
*.LBX retrieve changes other developers made.
*.lbt • If anything was retrieved:
*.LBT
o Merge the changes with your local
# Misc backup files folder and resolve conflicts as neces-
*.orig sary.
*.ORIG
*.save o Convert the text files to binary files.
*.SAVE o Repeat all of the above steps.
*.zip
*.ZIP • Once a pull retrieves nothing from the
repository, push to the central reposi-
# Other files
*.chw
tory.
*.suo
*.docstates

Page 4 FoxRockX March 2017


Figure 2. Version control workflow.
Next time
In the next article, the last in the series, we’ll look at
when to commit changes, when to push, strategies
for branching, how to fix common problems, and
using a cloud-based repository.
Author Profile
Doug Hennig is a partner with Stonefield Soft-
ware Inc. He is the author of the award-winning
Stonefield Database Toolkit (SDT); the award-
winning Stonefield Query; the MemberData
Editor, Anchor Editor, and CursorAdapter
and DataEnvironment builders that come with
Microsoft Visual FoxPro; and the My namespace
and updated Upsizing Wizard in Sedna.
Doug is co-author of “VFPX: Open Source
Treasure for the VFP Developer,” “Making
Sense of Sedna and SP2,” the “What’s New
in Visual FoxPro” series (the latest being
“What’s New in Nine”), “Visual FoxPro Best
Practices For The Next Ten Years,” and “The
Hacker’s Guide to Visual FoxPro 7.0.” He
was the technical editor of “The Hacker’s
Guide to Visual FoxPro 6.0” and “The Fun-
damentals.” All of these books are from Hent-
zenwerke Publishing (http://www.hentzen-
werke.com). He wrote over 100 articles in 10
years for FoxTalk and has written numerous
articles in FoxPro Advisor, Advisor Guide to
Visual FoxPro, and CoDe. He currently writes
for FoxRockX (http://www.foxrockx.com).
Doug spoke at every Microsoft FoxPro Devel-
opers Conference (DevCon) starting in 1997
and at user groups and developer conferences
all over the world. He is one of the organiz-
ers of the annual Southwest Fox conference
(http://www.swfox.net). He is one of the administra-
tors for the VFPX VFP community extensions Web site
(http://vfpx.codeplex.com). He was a Microsoft Most
Valuable Professional (MVP) from 1996 to 2011.
Doug was awarded the 2006 FoxPro Community Life-
time Achievement Award (http://tinyurl.com/ygnk73h).

FoxRockX™(ISSN-1866-4563)

Copyright © 2017 ISYS GmbH. This work is an independently produced

dFPUG c/o ISYS GmbH
Frankfurter Strasse 21 B
61476 Kronberg, Germany
Phone +49-6173-950903
Fax +49-6173-950904
Email: foxrockx@dfpug.de
Editor:
Rainer Becker-Hinrichs
publication of ISYS GmbH, Kronberg, the content of which is the
property of ISYS GmbH or its affiliates or third-party licensors and which
is protected by copyright law in the U.S. and elsewhere. The right to copy
and publish the content is reserved, even for content made available for
free such as sample articles, tips, and graphics, none of which may be
copied in whole or in part or further distributed in any form or medium
without the express written permission of ISYS GmbH. Requests for
permission to copy or republish any content may be directed to Rainer
Becker-Hinrichs.

FoxRockX, FoxTalk 2.0, FoxTalk, Visual Extend and Silverswitch are trademarks of ISYS GmbH. All product
names or services identified throughout this journal are trademarks or registered trademarks of their
respective companies.

FoxRockX is published bimonthly by ISYS GmbH

March 2017 FoxRockX Page 5

Seamlessly Read/Edit/Save
numeric data of variable
precision
Pradip Acharya
Numeric data of Integer and Floating Point types,
are commonly edited and saved using some
derived class based on the Textbox baseclass, then
setting a Format mask and so on. Integer fields will
have no decimal point and floating point fields will
have a precision of 2 decimals digits. Now consider
the constant Pi which is 3.14 to 2 decimal digits and
3.1415926536 to 11 decimal digit precision. How
would you like to read in 3.14 from the table field,
type in 3.1415926536, save, and read it back just as
saved. Chemical, Physical and analytical work or
chemical, mathematical or other entities are all of
variable precision. Example are Hg concentration
in drinking water or engineering tolerances. The
required xNumericbox class and demo program
are outlined in the article. The limiting constraint is
the maximum precision of 14 decimal places in VFP
64-bit double field type on good days. On bad days,
it can degrade to 13 decimal places.
Numeric Data are saved in four types of data
fields in VFP – I, B and F/N, I for integer, B for
Double floating binary and F/N for 4-byte fixed
decimal point floating point. The method outlined
here applies only to Double B editing because the
F & N types are permanently stamped with fixed
­nFieldwith and nPrecision attributes, and not in
pure Mantissa and Exponent bit pattern.
Since this class does not enforce any fixed
­Format mask, this class is not to be used for han-
dling every day Money or Integer or fixed Decimal
fields.
Numeric data Precision Limits
The 8 byte D field has a usable precision limit of 14
decimal digits and a magnitude limit of:
4.940656458413E-324
8.9884656743114E307
52 bits are allocated to the Mantissa and 12 bits are
reserved for the Exponent.
The limiting numeric range in VFP shown
above is only of academic interest. It is of little
practical value since you cannot even multiply
Page 6 FoxRockX
Author Profile
Pradip Acharya is a Toronto based developer. Techni-
cally retired after 50 years in the software field, he still
dabbles in new concepts and helps out customers when
called upon. pacharya@sympatico.ca.
the limiting values by 2 or even add 1. Instead we
have arbitrarily chosen to use the square root of the
upper limiting value as practical usable range for
our xNumeric class and it works out very well.
The practical limits used for the class are:
-9.480751908109E-153
9.480751908109E+153
The Demo
At load time, the Demo Load method creates a tem-
porary cursor with a random file name. When the
demo ends. This cursor is closed i.e. Deleted.
As a side discussion, let's talk about creating a
truly random cursor name generation. The RAND()
function is used for this purpose. This function is
seeded with an initial call in the form RAND(5). If
you use the same initial seed, the generated num-
bers are the same for the same inputargument.
For the purpose of this article, we randomize
the seed which is a combination of a part of Today's
date and Seconds() of the current time. This creates
a random file stem which is unlikely to repeat.
Here is the code for random file name genera-
tion:
?"_"+ RIGHT(TRANS(DAY(DATE())),3)+;
RIGHT(TRANS(INT(SECONDS())),3)
An example of such a random name as the file
stem would be _27679.
The demo is in two parts. In the first part, you
will load a preset into the B field value in the cur-
sor, which this case is 3.14 which is the value of Pi
two decimal places. Now type in additional digits
to the right to make 3.1415926536E0 and click on
save. Reload. You will see the field value of D in
the edit box 3.1415926536E0. If you close the demo
form and reload, You'll be loading in the initial
value of 3.14.
The Demo - Part 2
Here we will create an external user table and save
edited data. Come back, and check the edited value
by reloading the field in the xNumeric box.
March 2017
 In the command window:
SELECT 0
CREATE TABLE MYTABLE(D B)
APPEND BLANK
REPLACE D WITH 1234.5678
Now we will load data from the external table
for editing.
This is done by:
m.oXnumeric.xNumeric1.Loadin('Mytable.D ')
Note the input parameter is the character string
ALIASNAME.FIELDNAME and not its binary
value of the field. So when you Save the edited
field, it will know where to update the edited value.
Change the value to 8756.4321 and save. It
saved the data to your table.
If you now do:
m.oXnumeric.xNumeric1.Loadin('Mytable.D ')
You will see the data was permanently saved in
its edited form.
Class Library xNumeric.Vcx
First task is to load binany data and convert to a
character string for editing. The conversion to
string is done by checking the range of the number
and selecting the appropriate option including the
Exponent style. To see the ranges and branching,
look into the ProgrammaticChange method.
Although the theoretical range is
+/-4.94065645841247E-324 to
+/-8.9884656743115E307
this is meaningless since these numbers can
not even be squared. An arbitrary limit of
+-9.480751908109E+153 which the square root of
the smaller number is set as the range limit.
There are a set of character positions to parse
the text and to use these to write out in its table
storage loation, when done. To be noted, the Loa-
din procedure accepts the character location as
­Aliasname.Fieldname and uses it to update the
binary data back in the table.
Keystroke management
The class also features sophisticated keystroke han-
dling code under the keypress procedure to slot
characters in their right place.
Binary to character for editing
The event handling required for this binary to
string conversion is hard to describe. Let's take it
granted since it works.
The Parse function
As each character comes in, this function re-scans
the text string to update the marker parsing prop-
erties.
March 2017 FoxRockX
The markers are:
idot Position of the Period
iepos Position of the exponent E
i1st1to9 Position of the first 1-9 digit
isminus Is there a -sign in position 1
n0to9 Total 0-9 digits
n1to9 Total 1-9 digits
ntextlen Text length of the numeric string
The markers are used by the KeyPress event
to pass or block incoming characters and also for
string to numeric conversion.
Different ranges, different editing
The ProgrammaticChange procedure of the Class
xNumeric selects the applicable editing scheme
and sets the stage for editing for the incoming Dou-
ble Float number by selecting a range based display
and editing scheme.
We are using a TextBox of width 20 for display-
ing and editing a type Double (D B) number as in
our demo form xNumeric.
For type Double (D B) numbers, there are two
schemes, based on the data range – non Exp plain
and Exp type. If the absolute value of the (number
<= 999999999999.99) use Non-Exp scheme edit the
number as text string = TRANS(Number).
If the absolute value of the (number <=
9.480751908109E+153) range limit edit the
number in Exponent format as Textstring =
TRANS(Number,'@^') Exp style otherwise number
is out-of-range report error 'Data out of range' and
do nothing.
Brain damaged F and N
Datatypes
Let's create a table with a B type field and a F type
field.
Create table mytable(D B, F F)
Append blank
replace D with 123.456, F with 123.456
To view internal data as in its native form, you
need to use the Transform function with format
mask “@^”
?TRANS(D,"@^")
?TRANS(F,"@^")
You see that D field reflects back the exact data
and the F field was saved with the format stamped
on it.
To me this is a strange concept probably origi-
nating in the Xbase specifications and widely popu-
larized by Dbase. Not for me and I don't use it. I
don't know the difference between F and N field
types, probably they are the same.
Conclusion
In order to work with numbers of more then 14
decimal precision, one will need a 128 bit machine.
But then, I don't know if VFP itself will work.
Page 7
Continuous Integration with
Jenkins and Visual FoxPro
Eric Selje
This article discusses improving the Software
Development Lifecycle for Visual FoxPro devel-
opers. We'll begin by reviewing the typical devel-
opment cycle, and show ways to improve and
automate our current process using a Continuous
Integration server and open source tools from VFPX
such as Automated Build, FoxUnit, and source con-
trol tools.
A Typical Day in the Life of a VFP
Programmer
Eric (his name has been changed to protect his
identity) is a typical Visual FoxPro developer. Eric
got on board very early with the Fox. He learned
very quickly in the late 80s that dBase was great
but FoxBase was far better. Eric was very excited
to when FoxPro came out, and when Visual Fox-
Pro 3.0 arrived in 1995, his development careeer
changed forever.
But in some ways Eric’s Visual FoxPro career
hadn’t changed much since. New version of Visual
FoxPro arrived regularly (up until recently), but the
basic way he created applications was consistent
throughout.
The Project Manager was always Visual Fox-
Pro’s command center for development. When
Eric wanted to work on an application, he’d fire up
Visual FoxPro, open the project in the Project Man-
ager, and do what needed doing. Testing involved
running the application and verifying it “did what
it was supposed to do.” Version control meant
hopefully remembering to backup the application’s
source code directory. Deploying meant building
an EXE and copying to someplace where the users
could get at it, and likely meant kicking everybody
out of the application so the update could be cop-
ied. It happened so often the users didn’t think
twice about it, assuming this was just the way it
had to be. Eric too thought this was the way all pro-
grammers did it. Perhaps you do too?
It doesn’t have to be this way.
Eric’s slow realization of this truth came when
he left the insular world of Visual FoxPro devel-
opment and was exposed to what other program-
Page 8 FoxRockX
mers did. He started hearing words he didn’t
understand, like “Git” when there were no horses
around, and “Mercurial” when there were no
thermometers. He started seeing applications that
would automatically update themselves while the
user was still running them, and “Nightly Builds”
dropping onto servers at times when all the devel-
opers should long have been home in bed.
When Eric finally discovered the powerful con-
cept of “Continuous Integration,” his mind was
blown. This was a concept that would once again
change the way he developed forever – if he could
get it all to work in Visual FoxPro.
A True Story
It’s the middle of the night. Your phone rings once,
twice…on the third ring you pick it up. It’s your boss
(or best client, whichever is applicable to you).
Groggily you say “Hello?” while hearing a sigh from
your tossing spouse.”
“Hey!” you hear, causing you to pull the phone two
inches away from your ear. “All of our nightly reports
are crashing! Fix it!”
Now slightly awake, you see it’s 3 a.m. The reports
just kicked in and immediately failed. You try to get
it together enough to recollect what you may have
done that day that would have caused this failure, and
you’re actually hoping it was your fault because if it
was another developer then you’re going to have to
murder someone on your team and then have to go
through the trouble of finding a replacement.
Eventually your synapses recall that one small opti-
mization you made to the function that most of the
reports use. Yes, that’s it. Easy fix…I’ll just put that
change back. Since your company doesn’t reliably use
version control, you’ll hopefully remember what the
code looked like before and put it back right.
You fire up the laptop, make the change, build it, log
onto your VPN, call the office, wait while everyone is
out of the app, and copy the new EXE to the three or
four different places it needs to go for everything to
run smoothly until you get to your desk in… only 3
hours?!
That “one little fix” took very little time to actually fix
but quite a bit of time to build and deploy. You hope
it works, but you’ll find out if it failed when the phone
rings again just as you’re drifting back to sleep.
March 2017
 I imagine that story makes you cringe. Just
writing it started stirrings of PTSD inside of me.
Now let’s investigate how Visual FoxPro develop-
ers like Eric can use Continuous Integration so that
none of us will ever have to suffer through an expe-
rience like that again.
What is Continuous Integration?
At the most basic level, Continuous Integration
(CI) means letting a tool, a Continuous Integra-
tion Server, automate the day-to-day tasks that you
have been doing manually. That means automati-
cally running the tests to ensure your code is good,
building the EXE from the project’s source code,
and copying the EXE to a place where others can
get at it.
Some Visual FoxPro developers have con-
cocted a collection of scripts and batch files to do
much of this mundanity, but a true CI Server is a
comprehensive, integrated tool with hooks you
can tap into in order to consolidate those disparate
scripts under one management tool. A CI server
gives you the extra functionality of creating status
reports that can be emailed and web dashboards
that allow you to quickly ascertain the status of all
of your projects at a glance.
How much would you pay for this amazing
Continuous Integration awesomeness? Well, you
could pay a lot as there are commercial products
available. On the other hand you could not pay
anything at all. Let’s look at some of our options.
Continuous Integration Servers
There are quite a few CI servers available (http://
en.wikipedia.org/wiki/Continuous_integration) ,
but here are some that are probably most likely to
be used by Visual FoxPro developers:
Commercial Offerings
Team Foundation Server (TFS): This is
Microsoft’s official offering. It’s much
more than just a CI server, it is also the
successor to Visual SourceSafe for ver-
sion control, has a facility for project
task list tracking, and reporting. This is
commonly used in Microsoft-only shops
and, in my experience, rarely used else-
where.
TeamCity: This program from Jet-
Brains, the Resharper folks, is the most
common name I hear when I ask which
Continuous Integration product other
developers are using. It is built to be
language-agnostic so it works well with
.Net, Java, Ruby, etc., and with plug-ins
can be modified to work with Visual
FoxPro as well. While I’ve listed here as
Commercial, it’s actually free for “small Figure 1. The Continuous Integration Cycle
teams.”
March 2017
Free and Open Source
CruiseControl: This open-source framework was
the first one I used because Markus Winhard had
already written a configuration file for Automated
Build. The original CruiseControl was written in
Java but was ported over to the .Net framework in
a fork called CruiseControl.Net.
Jenkins: Jenkins is my current open-source
favorite. It’s very simple to install, has a very small
footprint on my development machine, and is infi-
nitely configurable. Jenkins is the tool I’ll be using
in my session and for this whitepaper.
This is not intended to be a comprehensive list.
Please do some research before deciding which CI
server is right for you.
When you’ve chosen and installed your Contin-
uous Integration server and integrated all the plug-
ins you need for your project, you will have a com-
plete system that allows you to deploy software in
a repeatable, efficient manner that decreases errors
and increases your productivity.
This diagram (Figure 1) shows the continuous
integration cycle. The cycle begins when the devel-
opers at the top check in their source control to
the central repository. That causes the CI Server to
run Unit Tests, Integration Tests, Functional Tests,
Code Analysis, and whatever else you’ve plugged
in. If the tests fail, the check-in will be rolled back,
but if they succeed the project will be compiled into
an EXE. If the build passes (no compilation errors),
it can proceed to deploying the final product to
wherever it eventually goes. All along the way
reports can be generated and sent to the project
team to apprise them of the status of the project.
0F Ideally the tests pass, the build is created, the
executable is deployed, the client is updated, the
FoxRockX Page 9
developers are notified, and the cycle starts again.
The question then becomes, to borrow a title from a
classic, “Will the Circle Be Unbroken?”
Setting up a Continuous
Integration Server
To start, let’s set up a CI Server. This can be on your
development machine (which is the way I do it),
a Windows server on your network, or a ­virtual
machine in “the cloud.” It really doesn’t matter
where it’s physically located, but if it’s on your
development machine you are limiting the scale
to just one developer. If you think there’s a chance
you’ll ever involve more than one developer, or
you feel more comfortable putting your eggs in dif-
ferent baskets, consider putting the CI Server some-
where else.
You might imagine that a CI service needs to be
running on a powerful server somewhere but this
definitely not the case. It can run on any machine
that has access to the source control as well as any
additional tools required to do its job such as the
Build tool. It does have to be a Windows machine
though, because Visual FoxPro projects are Win-
dows-only and require a Windows machine to
build them.
Step 1: Use Source Control
Version control, while not absolutely necessary, is
preferred because CI servers have the ability to
monitor repositories of the most popular types,
and usually a source code check-in is the trigger
that fires the entire CI process. Hopefully by now
you’ve begun taking advantage of version control!
Even if you don’t work with other developers, you
need to be doing this.
If you don’t have an offline repository yet, just
search the web for any number of free/cheap ones.
In this figure I setup a free repo on ProjectLocker
and joined my test project to it in less than five min-
utes.
Serial Killer
One quirk of Visual FoxPro is that much of the
source code is stored in binary files (actually VFP
tables themselves) rather than text files. Binary files
are problematic for version control systems because
it’s rather difficult to “diff” them. The solution for
VFP developers then as always been to serialize the
table, i.e. turn it into an equivalent ASCII text file.
Projects that have been “Joined to Source Con-
trol” using Visual FoxPro’s built-in functionality
automatically get their binaries serialized via the
native SCCText.prg. This is an inferior program
and has long been superseded by any number of
projects, including VFPX’s SubFox and SCCTextX,
Christof Wollenhaupt’s TwoFox, or Toni Feltman’s
Page 10 FoxRockX
F1Utils.
If you prefer to do version control from the Win-
dows filesystem, you can use the fine Tortoise tools
for Subversion or Mercurial. Tortoise integrates
right into Windows Explorer. Tortoise doesn’t seri-
alize the binaries for you automatically though, so
you will need to be sure to take care of that manu-
ally using one of the tools mentioned above. SubFox
does have some nice hooks into Tortoise that auto-
mates the process.
The problem with all of these tools however is
that invoking the serializer/deserializer is a man-
ual process (SubFox’s hooks do deserialize binaries
automatically when you check out files from the
Tortoise interface, so it may have potential to from
a command line, but this needs further investiga-
tion into the source code. The other tools could have
wrappers written that allow them to do it as well.),
and with Continuous Integration we need things
to run automatically. Whichever of those tools you
use, some customization will be necessary in order
to get them to run from the Windows shell in order
to be integrated into Continuous Integration.
For this reason, I recommend that you do check
in the binaries into your version control system
along with the serialized version. That way they
won’t need to be deserialized when you run an
automated build, saving you this manual step.
The exception to this rule is the PJX/PJT files:
Do not check those into version control. Automated
Build, in the next step, will recreate the PJX file
from the “PJM” file that’s generated. Just be sure to
check in your PJM file!
Step 2: Install Automated Build
This is the utility that takes your source control and
creates an EXE out of it. Visual FoxPro developers
have always had to do this manually by clicking on
the Build button in the Project Manager. Now we
also have Automated Build, another VFPX tool, to
compile EXEs from the command line.
Automated Build was written by Markus
­Winhard. It’s actually just one PRG, BuildProject.
prg along with a few supporting files. See the full
documentation on VFPX, but the installation is
basically just copying the files needed to a folder.
Tip: You might be tempted to create an EXE so
you run Automated Build without needing a full
VFP deployment; However Automated Build uses
the command BUILD PROJECT, which is unsup-
ported in the VFP Runtime. You’ll have to copy the
minimum files needed to run the full Visual Fox-
Pro onto your CI server. This means you’ll need a
fully licensed copy of VFP for your CI server if it’s a
separate machine than your development machine.
If you use CruiseControl.Net as your CI server,
Automated Build has sample configuration plug-in
March 2017
files that make it very easy to inject Automated-
Build into your CI Cycle. For Jenkins we’ll have to
configure things ourselves as well, which we will
do later when we set up a real job.
GenPJM
BuildProject takes as a parameter the name of a PJM
file, which is the serialized version of the project’s
PJX/PJT file. If your project is joined to a source
control provider, the PJM is created automatically
for you. If not, you will need to generate that PJM
manually. A recent addition to the Automated
Build project on VFPX is GenPJM.prg, which will
serialize your project’s binary into a PJM file that
Automated Build can use.
Tip: Call GenPJM from a ProjectHook when-
ever the project is modified, saved, or built so you
don’t have to remember to do it manually. Remem-
ber, one goal of CI is to automate as much as pos-
sible!
BuildProject recreates the PJX file from the
PJM, compiles the source code, and creates output
that the Continuous Integration server can parse
and act on.
Are we done?
You could stop right there and just have a CI
server that automates builds periodically or when-
ever you check in source control. That alone would
probably save you a lot of time and effort. Let’s not
stop there - let’s add a couple more things to really
create a professional development environment.
Step 3: Set up Unit Testing Framework
(Optional, but Desirable)
Unit testing is often the first tool fired in the CI
cycle, occurring right after new source code is
checked into the repository. A good CI server can
be configured to proceed to a build only after the
source code passes the unit tests, or rollback a
check-in that causes unit tests to fail and send the
developer that tried to check in the failing code a
detailed report of the results.
Visual FoxPro developers have the excellent
FoxUnit framework to allow them to interactively
create and run unit tests while they’re developing,
but that doesn’t help us in an automated environ-
ment. Now that FoxUnit has also moved to VFPX,
an effort is underway to expand its functionality
to allow tests to be run from the command line so
they can be integrated into a Continuous Integra-
tion tool.
John Miller wrote an excellent article for CoDE
Magazine that details the work you need to do in
order to make FoxUnit work with Team Founda-
tion Server. Only slight modification is needed to
customize it to the Continuous Integration frame-
work of our choice, Jenkins.
March 2017 FoxRockX
And More
Continuous Integration Servers have “hooks” that
allow you to plug-in any number of 3rd party tools.
Properly modified, it would be possible to integrate
tools into your software development lifecycle that
check for “code smells”, plug into your issue track-
ing system or project management, deploy the soft-
ware to FTP servers or Content Delivery Networks,
and so much more.
Final Step: Set up a Continuous
Integration Framework
Finally we have arrived at the most necessary
step of all in order to implement Continuous
Integration, setting up the CI Server itself. I’m going
to use Jenkins, a popular open-source Continuous
Integration framework. You can read all about the
interesting history of Jenkins here. Installing Jenkins
on Windows is trivial, just download the .ZIP file
and run the SETUP.EXE on the machine that will
serve as your Continuous Integration server.
After installing Jenkins, you’ll have a new ser-
vice running on that machine which is setup to
run automatically when the machine starts. This
is likely what you want but you can flip it to start
manually if you’d rather.
The service monitors a port on your machine,
which by default is 8080. Fire up a browser and
navigate to the servername:8080 and you’ll see the
basic Jenkins dashboard (Figure 2).
Start by configuring Jenkins to your liking by
clicking the “Manage Jenkins” link to get the con-
figuration page (Figure 3). Notice how Jenkins can
check back with its home server and lets you know
when it is out of date. You can update with the click
of a button. Nice.
On the “Configure System” screen, you’ll want
to verify/change which port you’re using for Jen-
kins (Figure 4), as well as set up the email settings
in order to receive notifications (Figure 5).
Creating a Job in Jenkins
After Jenkins is configured we can proceed to cre-
ate our first “job”. Jobs are somewhat analogous
to “Scheduled Tasks” in Windows (or cron jobs in
*nix), in that they’ll run on a schedule or when a
specific event happens.
For our job we’ll create a “free-style” project
(Figure 6), giving us the most flexibility since we use
a non-standard setup. First we name and describe
our project, and perhaps give it a few other options
like how many old builds to keep around (Figure 7:
Name and Describe the Job).
Next we can set even more options, like a
“Quiet Period”, which sets an interval between
each build. This is useful when you have quite a
few developers submitting code a lot, to prevent
Page 11
Figure 2. Jenkins Dashboard

Figure 3. Jenkins Management Screen

Figure 4. Configure Jenkins Port Number

Figure 5. Configure Jenkins to send general EMail Notifications

Page 12 FoxRockX March 2017

Figure 6. Creating a new "Job" in Jenkins
Figure 7. Name and Describe the Job
the build from constantly firing every time a new
submission comes in. In Figure 8 (Advanced Job
options) I’ve throttled Jenkins to at most do one
build every 10 minutes (6,000 seconds).
By default, the “workspace” for a build is in a
folder underneath the default Jenkins install folder
(e.g. C:\Program Files (x86)\Jenkins\jobs\<project
name>\workspace). You might want it to be
somewhere else though, especially on Windows
machines so you don’t succumb to the virtualiza-
tion issues that come with writing files under C:\
Program Files. I prefer creating my workspaces
under C:\ProgramData.
Configuring Your Source Control
The next step is to tell Jenkins where your source
code is checked in (Figure 9). Out of the box (I guess
that expression doesn’t really apply these days)
Jenkins supports CVS and Subversion, but there
are plug-ins for Mercurial, Git, and probably just
about any other version control system out there.
Note again that linking your CI Server to your
source control isn’t absolutely necessary. If you
choose not to link them, you will lose the abil-
ity to do a build automatically when source code
is checked in. That may not be an issue for you if
March 2017
you’d rather just do a build on a regular schedule
or create a build manually. If that’s the case just
select “None” for source control and you can set
your development folder as your Workspace. You
will lose a lot of scalability doing things this way,
but it might be all you need.
If you checked your binaries (VCX, SCX, FRX,
etc) into source control as I suggested, you now
have an extra step: You have to deserialize the
text files back into binaries before you can do the
build because VFP unfortunately can’t build based
on the serialized version (which is unfortunate
really, because one would think that internally
it’s reserializing the binaries before it does its
compilation anyway). There are a variety of ways
to do that depending on how they were serialized
but most would involve writing a wrapper around
whichever technique you used to serialize in the
first place. There is a lot of opportunity for some VFPX
volunteer work to be done here.
Set Up the Build
The most important step is to actually build the
EXE (or DLL) from our project. That means telling
Jenkins when to build and how to do it. Using the
Build Triggers (Figure 10), you can instruct Jenkins
FoxRockX Page 13
Figure 8. Advanced Job options

Figure 9. Source Code Management

Figure 10. Scheduling an Automated Build

Figure 11. Build manually anytime by queueing up a build with this button

Page 14 FoxRockX March 2017

Figure 12. New options available after the Jenkins Build Timout Plugin is installed
to poll the Source Control repository if you set one
up in the previous step, build periodically using
a very flexible syntax, or build after other Jenkins
projects get successfully built, which is great for
projects that are dependent on other projects.
You don’t have to schedule the build at all. Any-
time you want to build you can fire up the ­Jenkins
dashboard and click on the “Schedule Build” icon.
That will queue up a build to begin immediately.
Tip: Hover over that icon and look at the address
bar on the bottom of the browser. Because Jenkins
is web-based and has a well-written API, you can
use that same URL to invoke a build (e.g. http://
(CI_Server):8080/job/(Project)/build?delay=0sec).
Just add a button to your VFP Developer Toolbar
(which is very easy if you use Thor) that calls that
URL (simple with a RUN /N CURL.exe or either
WestWind IP Stuff or VFP2C32) and you can have
a build fire at the push of a button.
The last step in scheduling a build is telling
­Jenkins how to do the build (again, Figure 10).
Here we’re using the full version of VFP (because
we need to use the BUILD PROJECT command) to
call automated build (BuildProject.prg). The syntax
for BuildProject is
BuildProject.prg PJMFile [ManifestType, EXE
Name]
PJMFile is the name of the serialized PJX file
created with either GenPJM or our source control
tool if you’ve joined your project to source control.
ManifestType is either ADMIN or USER to
indicate the execution level (default is USER).
March 2017 FoxRockX
Once you’ve got your Build action described,
go ahead and test it by clicking on the icon to queue
up a build immediately (Figure 11). You should see
the “Last Success” time update automatically and a
pretty sun icon to indicate all is well. Clouds would
indicate things aren’t going so well. Clearly the
developers of Jenkins aren’t goth.
Failed Builds
If an Automated Build fails, perhaps because of a
syntax error or a missing file or anything else that
can cause a build to fail, it currently just sits there
and doesn’t exit properly. Markus is aware of this
problem and we’ve spent some time trying to fig-
ure out quite why it’s happening, but it turns out
there’s a nice workaround in Jenkins for this so it
doesn’t break things at all.
If you go back to the root of the dashboard
and choose “Manage Jenkins” and then “Manage
Plugins” (or type http://<CIServer>:8080/plugin-
Manager/? into your browser’s address bar) you
can select from over 300 plug-ins currently avail-
able for Jenkins. One of them is called the “Jenkins
Build Timeout Plugin” and it’s just what we need.
Install that plugin to add a new option on the Job
Configuration page called Build Environment (Fig-
ure 12).
The plugin is nicely configurable, allowing us
to specify an absolute time to abort the build, an
elastic time based on how long previous builds
took, or a “likely stuck” time based on some algo-
rithms built into the plugin. Here I’ve chosen to say
“Abort the build if it takes more than 150% of the
time that the last 3 builds took; if there haven’t been
3 builds yet then abort after 2 minutes.”
Page 15
 Now if I introduce an error into my code and
try to build, I’ll get a cloudy icon indicating all is
not well, but Jenkins will not hang. You can find
the .ERR file in the workspace folder to see what’s
causing the problem (Figure 13).
Adding Build Actions
Now that your build is scheduled and executing
properly, you can add more build actions. The
new actions can be sequenced either before or after
the actual build by dragging the actions around
the screen. There are over 300+ plugins available
currently for Jenkins, but very few are applicable
to Visual FoxPro. Though we are a bit limited as
compared to some of the other development tools
right now, though perhaps we can use VFPX to get
our tools up to snuff. Here are some ideas for build
actions:
E-Mail Notification
Jenkins includes functionality to send emails when
a build fails (Figure 14.). This is useful when you’ve
scheduled your builds to run automatically and
aren’t keeping your eyes on the dashboard.
Unit Testing
Ideally you’ll want to run your unit tests before you
actually build, and abort the build process if any of
the unit tests fail. But FoxUnit, the de facto unit test-
ing framework for Visual FoxPro, was not created
with Continuous Integration in mind. It’s not call-
able from the command line to execute unit tests,
and it cannot create the types of “console applica-
tions” necessary to write to STDOUT, so we’re in a
bit of a quandary.
Fortunately John Miller has started us down a
road that will take care of this problem. Check out
the code in the article referenced above. I haven’t
quite gotten it working perfectly yet myself and so
I can’t write as much as I’d hoped to on this topic,
but I would welcome any contributions to the Fox-
Unit project in this direction.
Figure 13. A Failed Build
Figure 14. Send email when a build fails
Page 16 FoxRockX
Code Analyst
This VFPX tool runs a “sniff test” on the code to
ensure it conforms to standards and is well-written,
based on built-in rules and rules you create. Cur-
rent rules included with the project check your
code for problems such as:
• Are there any RETURN statements with-
in a WITH /ENDWITH block?
• Are you using CTOD() anywhere? (This
doesn’t internationalize well)
• Does each function have a RETURN?
• And much more, plus you can write your
own rules.
Like FoxUnit, Code Analyst will need a wrap-
per in order to make it usable from a CI Server, but
we have the talent in our community to do this.
Deployment Tool
This is the tool that copies your EXE to wherever it
needs to go. It may be as simple as copying it onto a
shared folder or as complex as creating a variety of
Setup executables for different platforms, upload-
ing them to a secure FTP site, and updating a web
page with links that points to the latest versions.
Continuous Integration servers usually come
with functionality to deploy your EXE in the most
common ways, but you may have unique needs
that require you to use something special.
For example you might run an InnoSetup script
that bundles your files into a SETUP.EXE with auto-
updating ability. That would be nice and fairly easy
to integrate into CI, but it’s beyond the scope of this
whitepaper. See Rick Borup’s whitepaper from a
few years ago on using InnoSetup with Visual Fox-
Pro, and then just add the Inno script as a Build
Step after the project is built to create the SETUP
file.
Once you’ve include a deployment step into
your CI cycle you’ve gone beyond Continuous
Integration into the realm of Continuous Deploy-
March 2017
ment. This is a logical step to automate and it cre-
ates some more possibilities and issues, such as
where to deploy nightly builds vs. stable builds.
And More
Other development environments may include
other checks to ensure code integrity before a proj-
ect is deployed – tools for which no native VFP solu-
tion exists. That means there’s room for ­creative
folks like you construct the tools, or customize an
existing tool to do the job for us. These tools might
include:
• Integration Testing: These are tests that
make sure that your code works well
with others, like the database, the web
services, the mail server, etc. I’m not
aware of any frameworks that are made
specifically for FoxPro but many are
adaptable. It would also be acceptable,
though perhaps not “pure,” to write Fox-
Unit tests that are actually not strictly
unit tests but also integration tests.
• Functional Testing: These are tests for
the User Interface of your system, rather
than the business logic which is what
Unit Testing is aimed at.
• Load Testing: Tests how your applica-
tion would fare when many users are
hitting it at once. These sorts of tests
spin up multiple instances of your app,
often on multiple machines, to simu-
late real-world conditions. It’s amazing
how some apps that work fine when the
developer is testing things don’t perform
as well under load.
• Coverage Testing: These tests simulate
paths through your code to see which
code is getting nailed and which code
may not be touched at all. They perform
something similar to what would hap-
pen if you SET COVERAGE TO a file in
the beginning of your application, ran it
all day through every code path possible,
and then ran the coverage analyzer after-
wards.
• So Much More: Take a look at the plugins
page of Jenkins to see the plethora of
options available to you. Want to Tweet
when your build succeeds? Fire a growl
notification? Make an entry in a data-
base? Run a StyleCop on your HTML
code? There’s so much more you can
do with an extensible CI framework like
Jenkins.
Conclusion
Attempting to integrate your Visual FoxPro solu-
tions into a Continuous Integration process exposes
the limitations of Visual FoxPro: the inability to
March 2017 FoxRockX
c­ reate console apps, the binary source code, and the
lack of a native deployment tool create difficulties
for the developer. However given some patience
and a few workarounds, we can take advantage of
Continuous Integration.
I’ve attempted to use as many VFPX projects in
this session as possible, exposing opportunities for
improving the utilities. I implore you, dear reader,
to get involved. Throughout this whitepaper I’ve
indicated several places where VFP could use a
little more help to make Continuous Integration
useful and easy for every programmer.
I hope the concept of Continuous Integration,
and the specifics of how to implement it into your
Visual FoxPro Software Development Lifecycle, are
much clearer to you for having read this whitepa-
per and/or attended my Southwest Fox session.
This is a necessary process for serious developers
to integrate into toolbox, because like any good tool
it will make you more efficient and reduce errors.
Happy coding, and may your continuous inte-
gration cycle forever be unbroken.
Dedication
More details about the individual VFPX tools used
in this whitepaper are available in the recently pub-
lished book VFPX: Open Source Treasure for the VFP
Developer. Many thanks to the authors of those tools
for creating the parts we needed to put together
this entire system.
John Miller was way ahead of his time, writing
about pretty much this very topic way back in 2007.
I came across his article when I was writing about
Automated Build for the book mentioned above,
but ironically had already forgotten about it when
I was writing this. It was while rereading my own
chapter in the VFPX book that I stumbled across
my reference to his earlier article. This whitepaper
restates, probably less elegantly, most of the same
points he made way back then. For more informa-
tion about this topic I encourage you to read his
article.
Author Profile
Eric Selje is a software developer in Madison, WI. He has
been programming in Fox since FoxBase 1.21 in 1986 and
recalls eagerly waiting for the box from UPS with "FoxPro".
In 1995 he founded MadFox, the Madison, Wisconsin, FoxPro
User Group, after attending DevCon in San Diego and real-
izing that learning Visual FoxPro 3 would take a group effort.
Eric works as Salty Dog Solutions, LLC, developing business
applications for the desktop, web, and most recently mobile devices
with an emphasis on database-driven applications. He is also co-
author of VFPX: Open Source Treasure for the VFP Developer.
Besides FoxPro, Eric loves playing Ultimate frisbee and baseball,
solving crosswords, and reading all genres of books. To make
dependencies even more obvious, you could maintain properties
that keep references to every other object. The code then becomes
Page 17

Continued from Page 24
With a service locator you solve two problems:
There is no need, anymore, to launch the entire
application environment with all its dependencies.
Rather, you can launch the required parts at the
time they are required.
Moreover, if you now are faced with the
requirement to test the code above, you can easily
provide a different service procedure in your test
program file. Local procedures always have pre-
cedence over external procedures. This allows you
to alter the behavior of the service locator without
changing the code in the class. You can now easily
provide mock up implementations of all required
services, which also makes the unit test act as a doc-
umentation of all dependencies.
LOCAL loCustomer, loInvoice
loCustomer = This.oCustomerFactory.New()
loCustomer.Load ("ALFKI")
loInvoice = loCustomer.FindLatestInvoice()
If loInvoice.IsOverdue() ;
and loInvoice.IsNotPaidInFull()
This.oReportService.Print( ;
This.oUser.GetReportPath()+;
This.oReportRepository.get("WHATEVER")
) Also, the syntax in VFP isn’t as concise as the
Endif
Now all references are immediately obvious
by looking at the class definition. There are several
possibilites to actually fill those references.
The key is, if you want to avoid hidden depen-
dencies and invert the control of dependency, you
have to avoid the following common approaches:
• Create an instance of a named class in
code
• Access global objects unless there’s
an isolated technical reason such as in
menus and reports
• Rely on any other file
Instead you need to
• Provide only few channels to let objects
communicate with each other
• Spell out dependencies by using object
references in each object
SOLID for VFP developers
Not all of the SOLID principles are equally suited
for VFP developers. We need to be aware that we
don’t have strong typing and therefore can’t worry
about interfaces. We should keep the relative cost
in mind when we create empty abstract base classes
or use protected properties. Too many objects can
have a negative impact on VFP, so we clearly don’t
want to use as many objects as a C# developer.
.NET one. We can’t chain method calls. Creating
instances requires a lot more coding. We there-
fore have to strive for a balance between reducing
dependencies between objects and keeping our
source code readable.

DOWNLOAD

Subscribers can download FR201703code.zip in the SourceCode sub directory of the document
portal. It contains the following files:

doughennig201703_code.zip
Source code for the article “Lessons Learned in Version Control, Part 2” from Doug Hennig

pradipacharya201703_code.zip
Source code for the article “Seamlessly Read/Edit/Save numeric data of variable precision”
from Pradip Acharya

christofwollenhaupt201703_code.zip
Source code for the article “With abbreviations to success” fromChristof Wollenhaupt

Page 18 FoxRockX March 2017

With abbreviations to
success
Christof Wollenhaupt
TLAs put into Practice: Object
Oriented Principles in VFP
TDD, OCP, LSP, ISP, DIP, DRY, IoC, LOC, SRP,
DbC, CDD, DDD: Our world is filled with three
letter acronyms that are meant to make our lives
easier, if only we could remember what each of
them means.
TLAs explained
In this article we cover many of the acronyms used
in object oriented programming, especially in clean
code development. The purpose of this section is
to act as a reference which you can consult from
time to time to refresh some of the principles and
approaches. You should be able to read each section
just by itself.
SOLID
SOLID is neither a principle, nor a three letter
abbreviation. Much like LISA G. in the Visual
FoxPro community, SOLID acts as a shortcut for
remembering the order of events during launch-
ing a form (Load, Init, Show, Activate, GotFocus).
SOLID’s main purpose is to reinforce some of the
more important principles. Those are:
• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov-Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)
Certainly I don’t need to point out that the first
letter of each principle adds to word SOLID. They
are important principles, yet not the only impor-
tant ones. Principles such as SoC and DRY play in
the same league as those five. Obviously, Robert C.
Martin - who came up with the name SOLID - had
to pick those that fitted.
SRP - Single Responsibility Principle
To quote Robert C. Martin:
A class should have one, and only one, reason to change.
A variation of this principle has been known
to the Visual FoxPro community for some time: A
method should do one thing and one thing only.
March 2017 FoxRockX
Andy Kramek repeated this over and over in his
sessions about OOP in the 90ties. Many develop-
ers have followed this rule, yet, most Visual FoxPro
code violates the Single Responsibility Principle
in dramatic ways. SRP applies to the class, not the
method. Let’s look at typical examples:
Define Class Customer As Custom
Procedure MoveNext
* moves the record pointer to the next
* customer record
EndProc
Procedure IsValid
* validates customer data before saving
* them
EndProc
Procedure GetInvoices (tnYear)
* Returns a collection of invoice
* objects for the current customer and
* the requested year.
EndProc
EndDefine
In many frameworks - not just in the Visual
FoxPro world - but also in Java, .NET and other
languages, business objects act as a dumpster for
about almost everything that is not data related or
clearly UI. Everything that is loosely related to the
customer or the technical representation of the cus-
tomer in our application is put into the one single
class called the customer business object.
So what’s wrong with that?
Quite a bit, actually.
Can you imagine placing an order on the phone
and having the operator ask you: Does this order
exceed your order limit? Probably not. Yet, when
we model this process in software, we don’t think
twice about adding a GetCreditLimit method to
our customer object. In the real world, we wouldn’t
ask the customer to provide all invoices we have
sent him in the past year. In our software world
that’s however often a key function of a customer
business object.
What do a nail and your maintenance budget
have in common? Both are required to keep your
house intact. Normally, though, you wouldn’t
think of them as going together.
Page 19
 In the sample object above we are mixing
exactly those two. There’s a record pointer that is
get moved and invoices that are retrieved. That’s
mixing abstraction layers as well as mixing respon-
sibilities.
Even more frequently we see this kind of mix-
ing responsibilities with the form object and the
form class - which are kind of used interchangeable
in VFP.
In 20 years of doing Visual FoxPro consulting
virtually every framework that I encountered had
a set of form classes. Mostly they start with a base
form, continuing with two branches into dialogs
and edit forms. Edit forms are further split into data
entry forms, one to many forms, and so one. These
forms have methods like Next(), Print(), Save(),
Validate(), etc. that can be called by controls on the
form or the toolbar. There are properties to specify
the alias or business object of the main data source.
Common advice on using these classes usually
goes along the lines of: Add the control you want.
Then immediately add a method to the form to per-
form the action and call this method from the Click
event (or whatever event we are talking about).
Never put code into the Click event. Often this con-
tinues on how naming conventions are important
for form methods and how you should use com-
mon prefixes to group methods together in the
Properties Window that belong together.
Can you see what’s wrong with this?
Classes are not procedure libraries that do all
kind of stuff. They are not units of code that keep
similar methods together. Classes have a purpose,
have one purpose.
What’s the responsibility of a form?
A form hosts and groups a number of visual
controls in order to let the user interact with them
as a single unit.
It’s a visual control. Most controls are visual
controls. Their only purpose - hence their only
responsibility - is to let the user interact with the
application. A form captures and displays informa-
tion. That’s what a form does on paper, that’s what
a form class does in Visual FoxPro.
Every other responsibility has no place in the
form class itself. If a form checks user permissions,
validates input, navigates in a table, returns bits
and pieces of status information, these are all sepa-
rate responsibilities.
In most but the simplest applications you will
run into limitations if you place every responsibil-
ity onto the form. Can’t you show a second cus-
tomer on the same form? I want to edit some other
information on this form, as well. Can’t you show
related information on this form, but not on that
form. Of course, I want to edit data in a row in the
grid. I do it all the time in Excel. The confirmation
Page 20 FoxRockX
dialog is OK for those master data forms, but not in
the order entry dialog, and so forth. Customers can
be creative about what they want.
We can continue, but there are always requests
that do not fit nicely into these one-to-one or one-
to-many concepts we like to create. If you can’t
fulfill those requests, it’s not because it’s an unrea-
sonable demand from the customer, rather because
by merging responsibilities into a single class, you
increase coupling and decrease flexibility.
Data Validation, Navigating in a data source,
handling dependencies between input controls on
the form, maintaining state, checking permissions,
initiating reports, showing message boxes, all of
these are separate responsibilities that belong into
separate classes.
If you do more than one thing in a class, the
way you implement one thing impacts the way you
implement other things. Take refreshing the form
as an example. You need to do this when moving
the record pointer, when picking a value to show
related detail information, when changing data due
to validation rules. Because all of this code resides
more or less directly in the form, there’s no hesita-
tion to directly call the Refresh method.
But what if you later realize that calling Refresh
takes a lot of time for some controls because they
initiate a server lookup over an ODBC connec-
tion? Now you can’t simply replace Refresh han-
dling with an optimized version that keeps track
of which elements have changed and which have
dependencies without testing and changing all of
those responsibilities, as well.
OCP - Open-Closed Principle
Robert C. Martin defines OCP as
Software entities (classes, modules, functions, etc.)
should be open for extension, but closed for modification.
The basic idea behind this is that you write
code, test it and use it. Period. When you need new
features you write new code in a new class, test it
and use it.
You don’t modify the original class to add the
new feature. Admittedly, this is a principle that is
quite difficult to follow all the time, especially in
Visual FoxPro where classes are no first-class citizens.
In the context of the Open-Closed principle
modifications are changes in the way the class
should operate. Commonly those are caused
by new requirements. We are not talking about
bug fixes and refactoring. The code in a class can
change, should change and must change over time.
The purpose, the responsibility, the interface of a
class shouldn’t change, however.
If you take out your phone and look at it, what
you see is quite different from the following pic-
ture:
March 2017

Source: Flickr/Terekhova
Can you remember the day this phone turned
into your brand new iPhone 7 or a Samsung Galaxy?
I can’t, because those changes came slowly.
One day the dial wheel was replaced with keys,
the wire disappeared, microphone, speaker and
dial pad moved into one single device, recharge-
able batteries got added, a single line display was
added, a basic phone book was introduced, the
time was shown some day on the display, missed
calls and caller ID became available, a multi line
display was added, menus replaced the program
key, new networks where established, small games
where added, as was texting, PDAs merged with
phones, MP3s were invented, memory was added
to phones, videos, internet, browsers, keys dis-
appeared, pens disappeared, GPS sensors were
added, touch screens...
Every change was just a minor enhancement
over the previous version. If you kept up with tech-
nology, every step was easy to learn and came more
or less natural. Now imagine you had never seen a
phone since the early 70ties and were handed an
iPhone to make a call.
Would you realize that this isn’t the remote for
your garage door? Would you figure how to unlock
and dial? Would you wonder why you should eat
without feeling hungry when people keep talking
about menu options?
Changes to classes are just like this.
You change a little bit here, a little bit over
there. Add a new method, expand on the param-
eter list. A few DO CASE here, support for a new
feature in VFP there. Unless you rigidly test your
changes every time, you most likely end up with
a class that wouldn’t work unchanged with other
classes you wrote initially together with this class.
The problem is that every change seems to be
backward compatible, but that’s usually only true
in the context of your current focus. If those “non-
breaking” changes require a tweak in one class and
another SET CLASSLIB statement in the main pro-
gram, you just add it at this time... in the applica-
March 2017 FoxRockX
tion you are currently working in. If the same class
is used in other applications, it’s easy to miss those.
When classes are used by a team or an even larger
group of customers, you as the developer simply
don’t know in which contexts this class is used.
Every assumption about safe changes is a risky
one in this case.
The Open-Closed principle favors clear abstrac-
tions and clear hooks. That’s easier done in C++,
C# or Java where you have interfaces and abstract
classes, where you can implement more than one
interface, and where the compiler validates your
code at the earliest possible time.
However, even in VFP you can identify the pro-
cesses that are likely to change and provide exten-
sion methods for them. This is obviously much
easier when your class design follows the Single
Responsibility Principle and you don’t have hun-
dreds of properties and methods to wade through.
LSP - Liskov-Substitution principle
Robert C. Martin explains it like this:
Functions that use pointers or references to base classes
must be able to use objects of derived classes without
knowing it.
Obviously, in Visual FoxPro we don’t deal with
pointers, just with references.
The Liskov substitution principle is almost
always learned to late. When developers start
learning object oriented programming and design,
there’s usually a heavy focus on inheritance. Deep
inheritance hierarchies are a clear sign for early
designs. At this stage developers usually miss the
experience of creating good inheritance structures.
One might say that the theoretical background is
still missing. Or, developers haven’t failed often
enough.
You need to discover a problem to appreciate
solutions that others have found before you.
Later on when developers would be ready to
apply the Liskov Substition principle more fre-
quent, they usually shifted to a composition based
approach with fewer sub-classes.
Essentially, the LSP states that a sub class
should behave exactly like the parent class. This is
much easier in software development than in real
life where sub classes (kids) usually do the opposite
of their parent classes.
This seems like an obvious consequence of sub
classing. After all, you are merely specializing the
behavior of a class and inherit the default behavior.
New behavior is added but existing not altered. So
why make this a rule, and why should it be such
an important principle that it warrants to be in the
SOLID group of principles.
Page 21
 Yet, even in VFP base classes you can find vio-
lation of this principle. Take the form class’ Show
method as an example. The default behavior of this
method is to show the form and continue to run.
Now change the WindowType property in a
subclass and call Show again. Suddenly program
execution stops and when execution continues on
the next line the reference is gone.
Typically you won’t violate this principle
because you change the behavior of the sub class. A
more common reason is limiting functionality. You
might create a toolbar that has a print button. On
every form it calls a print method of some object
that in turn prints a default report for whatever
data is currently available. On some forms, you
might realize that there isn’t a single simple report.
So instead of printing a report, you either don’t do
anything at all, or display a dialog where the user
picks a report. Suddenly, the same method is show-
ing different behavior.
It’s not a major issue on such high level code.
However, if you work on data related object where
in one case transactions become too complicated,
so you just override methods in the class that
deal with transactions, or with the code to revert
changes, you also introduce subtle differences that
work in this particular instance, but will bite you if
you need to extend the scope of the class.
ISP - Interface Segregation Principle
If there’s a principle that VFP violates is the Inter-
face Segregation Principle:
Clients should not be forced to depend upon interfaces
that they do not use.
Visual FoxPro classes have dozens over dozens of
properties and methods. Most of them you never
use. Some of them you use in the designer but
never at runtime. Some you use to move the focus,
some perform validation, some control behavior,
some control instantiation, some handle data con-
versions, some handle color, fonts, size, some deal
with managing members, the Tag property is there
even “just in case”.
If you can’t split responsibilities into multiple
classes, or if a responsibility requires a different
interface depending on which side you are acting
from, then at least you should strive for coherent
interfaces.
In .NET and Java we can define interface and
implement them separately. In VFP we don’t
have this option. Adding layer over layer in VFP
wouldn’t help either. But at least try to make sure
that naming and documentation make clear which
members belong to which purpose of the class.
Page 22 FoxRockX
DIP - Dependency Inversion Principle
Robert C. Martin puts this principle in rather
abstract terms
High level modules should not depend upon low
level modules. Both should depend upon abstractions.
­Abstractions should not depend upon details. Details
should depend upon abstractions.
Of all SOLID principles I found the Depen-
dency Inversion Principle the hardest one to teach
in many years of being a consultant. There’s some-
thing in Visual FoxPro that inherently screams:
Violate the Dependency Inversion Principle! Just
ignore it! DIP can’t help you, it’s evil.
Well, that’s a bit of an exaggeration... It’s a fact,
though, that most traditional VFP applications vio-
late this principle.
When one learns writing programs, developing
applications, the intuitive approach is a top-down
approach. You have a problem, a big problem. To
solve this problem, you break it up into smaller,
more manageable sub-problems. Rinse and repeat
until problems are small units that you can solve
easily.
It’s an obvious approach, it’s a required
approach. As humans we need to break up big
problems, because we can only deal with so much
at a time. Huge complexity in great detail is not
what our brain was made for. How do you eat an
elephant? One bite at a time. It’s the most common
answer, but it’s wrong. That’s not what humans
would do (assuming we would actually eat ele-
phants).
Instead we would dice and slice the Elephant
into smaller parts. We would separate it into good
parts and bad parts. We would have parts that are
meant to eat, parts to throw away, parts to use for
something completely different, such as the teeth.
We would modularize the elephant and then han-
dle modules one bite at a time.
Modularization, breaking up, are such inher-
ent activities that we hardly notice when we break
one thing into several, even less think about how
and why we do it. We tend to realize modulariza-
tion only through the lack of it. When you have
a huge problem and don’t know how to tackle it;
when emotions seem overwhelming; when you just
don’t know what to do. Our top-down approach to
development is visible all over the place. This struc-
ture thrives the way we structure everything else.
We create projects, neatly organized into folders by
type. We group classes in class library or program
files. We break up classes into sections of proper-
ties, public methods and private methods.
Our application begins with a main program
that launches a menu, logs on the user, instanti-
ates a form, creates an application object. Our user
March 2017
interface is separated into parts that allow the user
to interact, the menu, toolbars, containers. Each of
them has action items, such as menu items, but-
tons, links. Each of those runs a module or a form.
The form breaks up into a UI, a dataenvironment, a
business layer. We have a main business object and
subordinate objects. Validation starts at the top and
uses smaller building blocks to perform validation.
Most structures we look at start with the big
picture and break down to the details.
What is good for some parts such as designing
a project or structuring the user interface, is a truly
bad concept for designing code.
The form depends on the business objects,
depends on global manager objects to validate
security access, depend on communication paths
to show dialogs or update status information. Busi-
ness objects depend on data objects. Data objects
depend on configuration. Error methods depend
on logging classes.
To see this in action, open the project you are
currently working on, pick the most complex form
in your application, switch to the command win-
dow and run the form.
Bets are high that you either receive an error
because the entire application infra-structure isn’t
available, or that behind the scenes the entire appli-
cation launches including logging you on and dis-
playing a menu.
A second example:
Take an empty project and add the main pro-
gram. Now recompile. If your project is organized
as most Visual FoxPro projects are, you should
end up with a project file that has pretty much all
required files in it or is at least prompting you for
those files.
Both is only possible, because the entire code
structure is organized in a top down way. Or, as
Robert C. Martin put it: Your high level modules
depend on low level modules and abstractions upon
details. In other words: The application design vio-
lates the Dependency Inversion Principle.
Dependency Inversion is a strange term if not
explained. In real life we see dependency inversion
when parents depend on their kids from a certain
age on. However, that’s not what we’re talking
about here.
If a class, an object, or a module needs some
other resource to fulfill its primary purpose, than
we call this a dependency on this resource. Just to
make this clear here: A resource doesn’t necessarily
have to be a class or an object. It can be an external
file, a database, or in the case of VFP even the value
of a setting or a public variable.
A top-down approach makes these resources
available very early on.
March 2017 FoxRockX
In compiled languages such as .NET, C++ and
Java we introduce a dependency by using a type. In
C# this could look like this:
Customer aCustomer;
aCustomer = ... ;
getting the value from somewhere;
Invoice inv = aCustomer.GetLatestInvoice();
if (! inv.IsPaidInFull && inv.IsOverdue)
ReportService.PrintSomething();
We hard-code references to Customer, Invoice
and ReportService objects. Most likely, those
depend on further classes such as a database
connection. Some of those are initialized during
startup, some are only used when you call certain
methods, or upon certain conditions. The point is:
You just don’t know.
As long as you execute this code only in the
context of your application, it’s merely an inconve-
nience to always have to run the application, log
on, open the customer search form, enter a cus-
tomer name, search, open the customer and click
on whatever button executes the code above.
Being a developer you likely have found cool
short cuts to make this process much faster. If a
TESTMODE.TXT file exists, you are automatically
logged on as an administrator into your applica-
tion. An auto-run feature in your application auto-
matically launches the proper form. Searches can be
saved and easily retrieved with a button, whether
the user requested the feature or not, forms are
restored when the application restarts.
Remember though: If it’s cool, fix it!
Adding cool stuff to the application as a short-
cut to make development easier for you is the
wrong solution for the wrong problem. It’s prone
to introduce security risks, adds additional features
to the app that need to be supported and clutters
the user interface with functions that you need, but
the user doesn’t.
But I disgress...
If you look at the code from a Visual FoxPro
point of view, the problem virtually becomes non-
existent. Variables can hold any reference, not just
a specific type. GetLatestInvoice can return any
object. As long as it has the required properties, the
code continues to work.
More literature is written for C# and Java
developers than for FoxPro developers. If you see
a discussion about code dependencies, you likely
see hard coded types and typed variables in most
examples followed on why this approach is so
problematic.
Then you read about interfaces being the solu-
tion, because now you can separate the interface
and the implementation. You smile and keep read-
ing. FoxPro is smarter than C# or Java. You don’t
Page 23
need no interfaces. All of this overhead isn’t neces-
sary in Visual FoxPro. Any object will work, you
can even add properties at runtime. One sure can’t
beat flexibility... Interesting problem, the Depen-
dency Inversion Principle. But it doesn’t apply to
you, just to strictly typed languages.
Wrong.
Just because Visual FoxPro doesn’t introduce
the same dependencies as C# and Java, doesn’t
mean that they exist. Let’s look at this code:
LOCAL loCustomer, loInvoice
loCustomer = CreateObject("BizCustomer")
loCustomer.Load ("ALFKI")
loInvoice = loCustomer.FindLatestInvoice()
If loInvoice.IsOverdue();
and loInvoice.IsNotPaidInFull()
goApp.ReportService.Print(;
goApp.User.GetReportPath()+"\whatever.FRX")
Endif
There’s a hard coded business object being
instantiated here. One can safely assume that this
business objects somehow accesses a data base. As
there’s no mention of a database connection in this
code snippets between obtaining an instance of the
customer object and first using it, we can conclude
that the data access layer is somewhere hidden
within the customer object but we don’t know how
exactly.
We also have a dependency on a global appli-
cation object and its report service object.
There’s another dependency on the user object
to figure out the path. And finally, a bit hidden,
there’s a dependency on a separate FRX file. No
matter whether this file is embedded in the EXE, or
external on disk, it’s external to the class definition
and therefore a dependency, either way.
Whether you have a strict typed variable, or
you refer to some external resources you introduce
a dependency in both cases. As a FoxPro developer
a global object has long been touted as a way to
decouple an application.
Instead of relying on a goUser object, we have
this mediator object goApp that provides us with
an oUser property containing the user object. We
can always replace this user object with a different
one, if we wish. Hence, we decoupled the code and
achieved true separation of responsibilities and
flexibility.
Nope.
We didn’t. We merely replaced a single name
goUser with a compound name goApp.oUser and
thereby violated the Law of Demeter and intro-
duced another dependency. We now need two
objects instead of one that are tightly coupled. A
goApp object might be seen as a mediator object,
but it’s in fact a so called God object.
Page 24 FoxRockX
The problem with using goApp is twofold.
First, we rely on an object being available. Our
code fails if the goApp object isn’t there. Second,
we hide dependencies this way. If you look at the
public interface of the class, or at all properties and
methods in the properties window, you can’t see
on which object the class depends. Does it make
user of goApp.oErrorLog?
Does one of the parent classes use this object?
You need to go through the code in the class,
the code of all objects being called, the code of all
parent classes of this object, the code of all parent
classes of all objects that are called... In the end, you
pretty much need to wade through the entire appli-
cation to find out whether there are further depen-
dencies when you run this code.
So what’s the solution? First of all, forget
goApp, forget global application objects. If you
want to reduce the dependencies of objects you
must minimize the amount of possible interfaces.
You also must spell out all dependencies clearly in
the class definition. There are several approaches
to this.
One is the service locator. This is what Java
does in its J2EE implementation. Instead of relying
on multiple objects, all objects only rely on a single
object, the service locator. Such a service locator
has a very simply and clear interface. Usually, its
only operation should be to request a service object.
With a service broker, the code above becomes:
loFactory = Service("CustomerFactory")
loCustomer = loFactory.Create()
loCustomer.Load ("ALFKI")
loInvoice = loCustomer.FindLatestInvoice()
If loInvoice.IsOverdue() ;
and loInvoice.IsNotPaidInFull()
loReportSevice = Service("ReportService")
loUser = Service("UserService")
loReportRepository = Service(;
"ReportRepository")
loReportService.Print( ;
loUser.GetReportPath()+;
loReportRepository.GetName("WHATEVER")
)
Endif
You still have dependencies on other objects,
but those are now channeled through a single ser-
vice locator that is accessed by a service function.
If you provide service brokers - which is another
name for service locator - do not make them an
object. Then you need to know how to instantiate
the object which isn’t as easy it might sound when
your application consists of several EXE, external
FXP files or a lot of EXECSCRIPT snippets. A pro-
cedure is a better solution in this case.
Continues on Page 18
March 2017