Tame Your ActiveX Controls Doug Hennig - dFPUG-Portal

FoxTalk 

Solutions for Microsoft® FoxPro® and Visual FoxPro® Developers 

Tame Your 

ActiveX Controls 

Doug Hennig 

6.0 

ActiveX controls are forward, but not backward, compatible. This means that if 

you install a newer version of an OCX on your system, any applications you ship 

to people who have an older version installed will break. This article presents a 

reusable tool that solves this problem in a simple, easy-to-use manner. 

HOW was the period between Christmas and New Year’s for you? I hope 

it was relaxing. For me, it was awful. The reason: I posted an update 

to Stonefield Database Toolkit (SDT) on our Web site just before 

Christmas. Anyone who downloaded and installed it immediately got an 

“OLE class not registered” error when trying to use SDT. I fielded a ton of 

support calls and e-mails the week after Christmas and had to come up with 

a fast solution to solve the problem for those folks and prevent even more 

calls later. 

What caused this problem? The main SDT form uses a TreeView control, 

and I had installed some software on my system that installed a newer version 

of COMCTL32.OCX, the OCX file containing the TreeView control. Even 

though I didn’t change the TreeView on the form, simply opening the form 

and saving it caused information about the newer control to be written to the 

form. Of course, very few others had this newer control on their machines, so 

even though the form wanted a TreeView control and they had a TreeView 

control, it wasn’t the exact control the form was looking for. Hence, the “OLE 

class not registered” error. 

Is it just me, or do you think this is incredibly lame too? I don’t care about 

different versions of the TreeView. I’d understand if I used new properties or 

methods of this control that didn’t exist in older versions, but as I mentioned, I 

didn’t even touch it in my copy of the form. 

I guess I only have myself to blame for being in crisis mode after 

Christmas. After all, I’d encountered this behavior before when I upgraded 

from VFP 5.0 to 5.0a; it came with an updated COMCTL32.OCX, and everyone 

Continues on page 3 

June 1998 

Volume 10, Number 6 

1 Tame Your ActiveX Controls 

Doug Hennig 

2 Editorial: Enter Sandman 

Whil Hentzen 

6 Best Practices: 

Development Checklist: 

Requirements Analysis 

Jefferey A. Donnici 

11 What’s Really Inside: 

Traversing Transactions 

Jim Booth 

12 Transactions: Tahoe and 

Microsoft Transaction Server 

Gary DeWitt 

15 Use the Microsoft Scripting 

Control to Script with VFP 

Rod Paddock 

18 The Kit Box: 

Synchronized Swimming 

Paul Maskens and Andy Kramek 

24 June Subscriber Downloads 

EA Cool Tool: The Best Tool 

is Knowledge 

Whil Hentzen 

Extended Article available at 

www.pinpub.com/foxtalk 

EA ActiveX and Automation 

Review: Where Should Your 

Automation Code Reside? 

John V. Petersen 

Extended Article available at 

www.pinpub.com/foxtalk

Enter Sandman 

Whil Hentzen 

WANT to get depressed really quickly? The next 

time you’re around a group of your peers, ask 

everyone to name the supergroups of the ’90s. 

By “supergroup” I mean the true superstar bands—the 

Beatles, the Stones, Zeppelin, The Who, Cream, CSN&Y— 

you get my drift. 

Yeah, I know. It’s currently chic to deride Mick, Keith, 

et al. It was also chic to rip on Cream. But you can still 

hear Badge being played at 110 decibels at the McKinley 

Marina on Milwaukee’s Lakefront any summer 

weekend—until the police show up. I don’t hear Boy 

George or Vanilla Ice (“I’m going to be the next Elvis 

Presley”) much, and Green Day and Jane’s Addiction 

aren’t going to warrant a footnote in Rolling Stone’s 

Seventy-Five Years of Rock ’n Roll retrospective. 

But my point is that there have been no new 

supergroups since about the mid-’80s. U2 is about the last 

one I can think of. Yeah, Hanson and the Spice Girls can 

fill a stadium in three hours now. But so could The Babies 

and Bananarama. These days, it’s crank out a couple of 

albums and disband. Make your $10 million and bail. 

“These youngsters—they don’t know good music 

anymore.” I yearn for the days of good old-fashioned rock 

and roll, when singers danced with live pythons on stage 

or bit the heads off of doves. 

Bands today lack staying power. 

Editor Whil Hentzen, Editorial Advisory Board Scott Malinowski, Walter Loughney, Les Pinter, Ken Levy, Publisher Robert Williford, 

Vice President/General Manager Connie Austin, Managing Editor Heidi Frost, Copy Editor Farion Grove 

FoxTalk (ISSN 1042-6302) is published monthly (12 times per year) 

by Pinnacle Publishing, Inc., 1503 Johnson Ferry Road, Suite 100, 

Marietta, GA 30062. The subscription price of domestic 

subscriptions is: 12 issues, $179; 24 issues, $259. Periodical postage 

paid at Marietta, GA and at additional mailing offices. USPS#005373. 

POSTMASTER: Send address changes to FoxTalk, PO Box 72255, 

Marietta, GA 30007-2255. 

Copyright © 1998 by Pinnacle Publishing, Inc. All rights reserved. No 

part of this periodical may be used or reproduced in any fashion 

whatsoever (except in the case of brief quotations embodied in 

critical articles and reviews) without the prior written consent of 

Pinnacle Publishing, Inc. Printed in the United States of America. 

Brand and product names are trademarks or registered trademarks 

of their respective holders. Microsoft is a registered trademark of 

Microsoft Corporation. The Fox Head logo, FoxBASE+, FoxPro, and 

Visual FoxPro are registered trademarks of Microsoft Corporation. 

FoxTalk is an independent publication not affiliated with Microsoft 

Corporation. Microsoft Corporation is not responsible in any way for 

the editorial policy or other contents of the publication. 

This publication is intended as a general guide. It covers a highly 

technical and complex subject and should not be used for making 

decisions concerning specific products or applications. This 

publication is sold as is, without warranty of any kind, either express 

or implied, respecting the contents of this publication, including 

but not limited to implied warranties for the publication, 

performance, quality, merchantability, or fitness for any particular 

purpose. Pinnacle Publishing, Inc., shall not be liable to the 

purchaser or any other person or entity with respect to any liability, 

loss, or damage caused or alleged to be caused directly or indirectly 

by this publication. Articles published in FoxTalk reflect the views of 

their authors; they may or may not reflect the view of Pinnacle 

Publishing, Inc. Inclusion of advertising inserts does not constitute 

an endorsement by Pinnacle Publishing, Inc. or FoxTalk. 

Subscription information: To order, call Pinnacle Customer Service 

at 800-788-1900, or 770-565-1763. Cost of domestic subscriptions: 

12 issues, $179; 24 issues, $259. Canada: 12 issues, $194; 24 issues, 

$289. Outside North America: 12 issues, $199; 24 issues, $299. 

Individual issues cost $17.50 ($20 in Canada, $22.50 outside North 

America). All funds must be in U.S. currency. 

For European newsletter orders, contact: Tomalin Associates, 

Unit 22, The Bardfield Centre, Braintree Road, Great Bardfield, Essex 

CM7 4SL, United Kingdom. E-mail: 100126.1003@compuserve.com. 

Tel: +44 (0)1371 811299. Fax: +44 (0)1371 811283. 12 issues: £179 

For Australian newsletter orders, contact: Ashpoint Pty., Ltd., 

9 Arthur Street, Dover Heights, N.S.W. 2030, Australia. 

Phone: +61 2-9371-7399. Fax: +61 2-9371-0180. 

E-mail: sales@ashpoint.com.au. Web: http://www.ashpoint.com.au. 

FoxPro technical support: Call Microsoft at 206-635-7191 

(Windows) or 206-635-7192 (Macintosh). 

Send all other questions or requests via the options at right. 

From the Editor FoxTalk 

And so does today’s software. 

I have a friend who runs the MIS department of a 

Fortune 200 company, and he’s getting ready to pull the 

plug on a bunch of boxes that have been collecting shop 

data (time clock type of info) since 1984. Same boxes, 

same software. None of this “upgrade of the month” 

business. None of this “make the chassis easily opened so 

you can replace broken parts in 30 seconds” rot. He’s 

replaced one fixed disk in 14 years. He’s not had to 

upgrade the boxes or change the software even once. And 

the best part? At the time he got these boxes, they’d been 

around for nearly a decade. (The equipment in question is 

the IBM Series 1, in case you were curious. And he’s going 

to replace them with Windows 95, er, Windows NT, uh, 

Windows 98, no, wait, make that NT 5, or . . .) 

I’ll bet you’re still doing a lot of the same stuff now 

that you were 10 years ago. Writing memos and technical 

documents. Calculating budgets and making cost 

estimates. Writing quote tracking, health care claim 

management, and accounting database applications. 

How much of the same software from 10 years ago are 

you still using? On the same machines? 

Boy, I wish it would stop. Or at least slow down a 

bit. I bet you do, too. But despite our most fervent wishes, 

it’s not going to. Why? It’s all these young kids in the 

industry who don’t have any perspective. “It can be done, 


Editorial and 

Subscription 

Information 

770-565-1763 

800-788-1900 

E-mail 

foxtalk@pinpub.com 

Pinnacle Web Site 

http://www.pinpub.com 

Applies to VFP v6.0 (Tahoe) 

Applies to VFP v3.0 

Fax 

770-565-8232 

Mail 

PO Box 72255 

Marietta, GA 

30007-2255 

Applies to VFP v5.0 

Applies to FoxPro v2.x 

Accompanying files available online 

at http://www.pinpub.com/foxtalk 

Applies specifically to one of these platforms. 

2 http://www.pinpub.com 

6.0

Tame Your ActiveX Controls . . . 

Continued from page 1 

who hadn’t upgraded to 5.0a got “OLE class not 

registered” errors when they tried to use SDT. My 

workaround at the time was to keep one machine in our 

office with VFP 5.0 (not 5.0a) installed and do any SDT 

development involving that one form with the TreeView 

on it on that one machine. If I ever forgot and modified 

the form on my machine . . . 

However, knowing I’d experienced the problem 

before didn’t make me feel any better when my Inbox had 

dozens of e-mails reporting the problem. That was the last 

straw; I had to come up with a permanent solution to this 

problem. The tool described in this article is the result. 

Background 

First, let’s look at the cause of the problem. If you open a 

form containing an ActiveX control as a table (in other 

words, USE MYFORM.SCX) and browse it, you’ll find 

binary information stored in the OLE field of the record 

for the ActiveX control. This binary information appears 

to contain some version-specific information about the 

control. As a result—at least in the case of the ActiveX 

controls shipped by Microsoft—ActiveX controls are 

forward but not backward compatible. This means that if 

I drop version 2.01 of an ActiveX control on a form, 

people with a newer version of the ActiveX control (such 

as version 2.02) can open the form, but those with an 

older version (like version 2.00) can’t. 

Let’s dig a little deeper and see how ActiveX controls 

are handled on a system. As you’re probably aware, 

simply copying an OCX file to someone’s hard drive 

doesn’t allow them to use the ActiveX controls contained 

in that file. The controls need to be registered on the 

system either using REGSVR32.EXE (a copy of this 

program comes with VFP) or letting VFP’s Setup wizard 

handle it for you. Using REGEDIT, we can see that 

ActiveX controls are registered by a class ID value in 

HKEY_CLASSES_ROOT\CLSID. For example, the 

TreeView control is registered in HKEY_CLASSES_ 

ROOT\CLSID\0713E8A2-850A-101B-AFC0- 

4210102A8DA7. There are several subkeys under this 

key, the most important ones (as far as we’re concerned) 

being ProgID, VersionIndependentProgID, and 

InProcServer32. ProgID contains the program ID, which 

might change from version to version—for example, on 

my system, the value of this subkey for the TreeView 

is COMCTL.TreeCtrl.1. VersionIndependentProgID 

contains just what the name implies (on my system, 

the value is COMCTL.TreeCtrl for the TreeView), and 

InProcServer32 contains the name and path of the OCX 

containing the control. This immediately suggests several 

potential problems: 

• The ActiveX control was never installed on a 

machine—there’s no entry in the Registry for the 

control, and the OCX doesn’t exist on the drive. The 

solution is to properly install it. 

• The OCX file was copied to the system but not 

registered—the file exists, but there’s no entry in 

the Registry. The solution is to use REGSRV32.EXE 

to register the ActiveX controls in the OCX. Hint: 

You must include the extension for the file 

you’re registering: 

"regsvr32 myfile.ocx" instead of "regsvr32 myfile" 

• The ActiveX control is registered, but the OCX can’t 

be found—it might have been moved or renamed, 

or the user might have restored from a backed-up 

Registry but didn’t restore all files. The best solution 

is to reinstall and register. 

• The version installed on the system is different 

than the one required by an application. While an 

obvious solution to this problem is to install the 

version of the control required, this might not always 

be feasible. For example, if I shipped my copy of 

COMCTL32.OCX along with SDT, that would get rid 

of my problems but would probably cause a whole lot 

of problems for you and any clients you’d created 

forms with a TreeView for. 

Another unforeseen problem can also occur. Some 

ActiveX controls look for a license (a key stored in the 

Registry or a file on your drive) in order to use them in a 

development environment. This makes sense; it allows 

you to develop and distribute applications using a 

vendor’s controls and have those controls work in a 

runtime environment while protecting the vendor from 

someone else being able to develop using those controls 

without paying for them. The problem this causes, 

though, is that if the license key gets lost on your system, 

you’ll get a “License not found” error when you try to 

drop the control on a form. Reinstalling doesn’t always 

solve the problem. Based on messages I’ve seen on 

CompuServe and the Universal Thread, this problem has 

been a common one. For the controls shipped with VFP, 

the solution is simple: Download a file called FOX.REG 

from the Universal Thread (there’s a great reason to join 

right there) and run it; it will register the proper licenses 

on your system. For other third-party controls, reinstall or 

contact your vendor. 

As you can see, most of the problems regarding 

ActiveX controls require reinstalling them. However, as I 

mentioned, it might not be possible to solve the version 

problem this way. The rest of this article discusses an 

easy-to-implement solution to this annoying problem. 

SFActiveX 

The solution is to instantiate ActiveX controls at runtime 

rather than using them at development time. This way, 

http://www.pinpub.com FoxTalk June 1998 

3

the control is instantiated from the version installed on 

the user’s system rather than looking for the version that 

was installed on your system. To make this job easier, I 

created an ActiveX loader class called SFActiveX. 

SFActiveX is based on SFCustom, our Custom base 

class defined in our base class library SFCTRLS.VCX. It 

has the custom properties shown in Table 1. 

Table 1. Custom properties of SFActiveX. 

Property Description 

cClass The name of the class defining the ActiveX control 

or a subclass of it 

cClassID The Class ID for the object 

cLibrary The name of the library containing a subclass of 

the ActiveX control 

cNewObjectName The name to give the ActiveX control this object 

will create 

cObjectName The name of the placeholder object to replace with 

the ActiveX control 

cOLEClass The OLE class for the object 

cClass defaults to “OLEControl” because that’s 

the VFP class that ActiveX controls are contained in. 

However, if you want to use a subclass of an ActiveX 

control (I’ll show at least one reason why you’d want to 

do that later in the article), enter the name of the class in 

this property and the name of the library file containing 

the class definition in cLibrary (specify an extension to 

identify VCX from PRG libraries). 

You can specify the ActiveX control to use in one of 

two ways: by cClassID or cOLEClass. If you specify one, 

leave the other blank. cClassID is the class ID for the 

ActiveX control, and cOLEClass is its ProgID. How do 

you know what to enter for these properties for a given 

control? For the cOLEClass, the simplest way is to drop 

the desired control on a form, then look at its OLEClass 

property. For example, the OLEClass for the TreeView 

control is “COMCTL.TreeCtrl” (you might see 

“COMCTL.TreeCtrl.1” in your instance; however, don’t 

worry about the “.1” for cOLEClass). cClassID is a little 

harder to determine. You’ll need to fire up REGEDIT and 

search for the OLEClass for the control, then see what 

class ID it appears under. For example, the TreeView 

control appears under “{0713E8A2-850A-101B-AFC0- 

4210102A8DA7}”. You don’t need to enter the curly braces 

when you enter this value into cClassID. It’s better to 

specify cClassID than cOLEClass because the name of the 

control might change when different versions are installed 

(for example, the TreeView control that shipped with VFP 

5.0a has a ProgID of “COMCTL.TreeCtrl.1”, which could 

cause problems under certain circumstances if you 

specified “COMCTL.TreeCtrl”). 

Some ActiveX controls have a visual appearance, and 

others don’t. For those that do, you’ll need to specify the 

location and size of the control. You could do it in the Init 

of the form by setting the Top, Left, Width, and Height 

properties in code, but I find it more intuitive to put a 

Shape object on the form and size and position it where I 

want the ActiveX control to go. This object becomes a 

placeholder for the ActiveX control, making it easier to 

size, position, and place other objects in relation to it. To 

tell SFActiveX that this object is the placeholder, enter its 

name in the cObjectName property. SFActiveX will 

remove this object and put the ActiveX control in its place. 

SFActiveX doesn’t have a lot of code. Its Init method 

calls the custom method LoadActiveX (which does all 

the work) unless told not to do so by passing .T. as a 

parameter (this is provided so you can instantiate 

SFActiveX in code, set the properties as appropriate, and 

then call LoadActiveX manually to load the control). I 

won’t address all the code in the LoadActiveX method 

here (you can check it out yourself), just the more 

interesting stuff. 

SFActiveX relies heavily on being able to look 

stuff up in the Windows Registry, because that’s 

where ActiveX controls installed on a user’s machine 

are registered. In order to work with the Registry, 

LoadActiveX uses the services of another class, 

SFRegistry, defined in SFREGISTRY.VCX. We won’t 

look at this class here; suffice it to say that I stole most 

of the code from REGISTRY.PRG, a Registry-handling 

class that comes with VFP, but made the programmatic 

interface a bit simpler. 

In order to use SFRegistry, you have to instantiate 

it; that work is done by a call to NEWOBJECT. 

NEWOBJECT.PRG is an updated version of 

NEWOBJ.PRG that I presented in this column in the 

September 1997 issue. It was updated to support the same 

syntax as the Tahoe NEWOBJECT function. This means 

that in Tahoe applications, you can omit this program, 

and any code calling it will work just fine. 

The first job for LoadActiveX is to figure out whether 

the desired ActiveX control is installed on the user’s 

system and, if the class ID was specified rather than the 

OLE class, which OLE class to use. The following code 

does this. Note that if you specify the OLE class and it 

can’t be found, LoadActiveX adds a “.1” suffix to the class 

and tries that before giving up. (The method starts with 

WITH THIS, so all unspecified object references are the 

class itself.) 

loRegistry = newobject('SFRegistry', ; 

'SFRegistry.vcx', cnHKEY_CLASSES_ROOT) 

if empty(.cOLEClass) 

lcCLSID = iif(left(.cClassID, 1) = '{', ; 

.cClassID, '{' + .cClassID + '}') 

lcProgID = loRegistry.GetKey('CLSID\' + lcCLSID + ; 

'\ProgID') 

llOK = not empty(lcProgID) 

else 

lcProgID = .cOLEClass 

lcCLSID = loRegistry.GetKey(lcProgID + '\CLSID') 

if empty(lcCLSID) 

lcProgID = .cOLEClass + '.1' 

lcCLSID = loRegistry.GetKey(lcProgID + '\CLSID') 

endif empty(lcCLSID) 

llOK = not empty(lcCLSID) 

4 FoxTalk June 1998 

http://www.pinpub.com

endif empty(.cOLEClass) 

if llOK 

lcOCX = loRegistry.GetKey('CLSID\' + lcCLSID + ; 

'\InProcServer32') 

llOK = not empty(lcOCX) and file(lcOCX) 

endif llOK 

At the end of this code, lcProgID contains the OLE 

class (ProgID), lcCLSID contains the class ID (which we 

don’t care about after this point), and lcOCX contains the 

name and path of the OCX file on the user’s system 

(found in the InProcServer32 key in the Registry). llOK 

is only .T. if we found what we were looking for in the 

Registry and the OCX file exists. If not, the user will get 

an error message, and this method will return .F. 

If everything is okay, LoadActiveX checks whether a 

placeholder was specified and, if so, saves its size and 

position and then removes it. 

llObject = not empty(.cObjectName) 

if llObject 

lcObject = .cObjectName 

with .Parent.&lcObject 

lnTop = .Top 

lnLeft = .Left 

lnWidth = .Width 

lnHeight = .Height 

endwith 

.Parent.RemoveObject(lcObject) 

endif llObject 

If a class and class library were specified, 

LoadActiveX opens the library (using either SET 

PROCEDURE or SET CLASSLIB, depending on the 

library’s extension). It then adds the ActiveX control or 

ActiveX subclass to the container, giving it the name 

specified in the cNewObjectName property. If a 

placeholder object was specified, the control is sized and 

positioned to the saved values. Notice the ProgID (stored 

in lcProgID) must be specified in the call to AddObject; if 

this was left out, the user would get a dialog box asking 

which control to insert. This is why we have to look in the 

Registry to determine the ProgID for the ActiveX control. 

lcObject = .cNewObjectName 

.Parent.AddObject(lcObject, .cClass, lcProgID) 

with .Parent.&lcObject 

if llObject 

.Top = lnTop 

.Left = lnLeft 

.Width = lnWidth 

.Height = lnHeight 

endif llObject 

.Visible = .T. 

endwith 

Using SFActiveX 

It’s easy to use SFActiveX: Simply drop it on a form (or 

other container, such as a page in a PageFrame where the 

ActiveX control should go), fill in some properties, and 

put code in the Init method of the form to set any 

properties of the instantiated ActiveX control as desired. 

To make it even easier to use, I’ve created subclasses of 

SFActiveX for the ActiveX controls I use most frequently: 

SFCommonDialog, SFImageList, and SFTreeView. These 

subclasses just have the appropriate class ID entered 

into the cClassID property so you don’t have to look it 

up. Drop one of these on a form to create the desired 

ActiveX control. 

Ah, but there’s one complication: What if you need to 

put some code in a method of the ActiveX control? This is 

frequently the case with visual controls—for example, 

with the TreeView and ListView controls, you need to take 

some action when the user clicks on a node or item in the 

list. In the case of the TreeView control, you’d put code 

into the NodeClick method. The problem, of course, is 

that you can’t add code to an object. The only way to 

accomplish this is to create a subclass of the ActiveX 

control, put the desired code into the subclass, and tell 

SFActiveX (via the cClass and cLibrary properties) to 

instantiate that class. One slight “gotcha”: You can’t create 

the subclass in a VCX because, like dropping an ActiveX 

control directly on a form, VFP puts binary information 

about the control into the VCX, and that’s the whole cause 

of the problem SFActiveX was designed to solve. Instead, 

you need to create the subclass in a PRG. Here’s the code 

from the sample ACLASSES.PRG that defines a subclass 

of the TreeView control; it has code in the NodeClick 

method (albeit simple code) that fires when the user clicks 

on a node. Note that OLEClass must be specified, or the 

user will get a dialog box asking which control to insert. 

define class MyTreeView as OLEControl 

OLEClass = 'COMCTL.TreeCtrl' 

Name = 'MyTreeView' 

procedure NodeClick 

lparameters toNode 

wait window 'You clicked on node ' + toNode.Text 

endproc 

enddefine 

Believe it or not, with all the problems we’ve solved 

using this scheme, we’re not quite out of the woods yet! 

There’s one last “gotcha”: Although you might think you 

could set some properties of the control in the subclass 

definition (such as Style and LineStyle in the case of the 

TreeView control), don’t do it. For a reason that escapes 

me, setting properties in the subclass seems to cause those 

properties to be carved in stone. Trying to change them 

later in a form the control is on fails completely. This 

means you have to set the properties after the control has 

been instantiated, usually in the Init of the form (which 

you can do, since by the time the form’s Init fires, the 

ActiveX controls have been instantiated). I’ll show an 

example of this in a moment. 

One final heads-up about the subclass: If you create 

an Init method in the subclass, it’ll need to accept a 

parameter. The OLE class is passed to the Init method 

(notice the third parameter in the AddObject call in 

LoadActiveX); although you don’t need it, you’ll get an 

error if you don’t have an LPARAMETERS statement. 

The sample TREEVIEW.SCX form shows how 

SFActiveX is used. This form contains three objects: an 

SFTreeView object (SFActiveX subclass specific for 

TreeViews) called oTreeViewLoader, an SFImageList 

object (SFActiveX subclass specific for ImageLists) called 

oImageListLoader, and a Shape called shpTreeView that 



5

Development Checklist: 

Requirements Analysis 

Jefferey A. Donnici 

With this month’s checklist column, Jeff takes a look at the 

process of gathering requirements for a development project. 

This column is the latest in a series of checklists designed to 

provide a starting point for your own development checklists. 

Building a set of system requirements is typically one of the 

first things to happen in a project and, as such, is an excellent 

opportunity to make sure that the project gets off on the 

right foot. 

AFTER covering coding, peer reviews, and a multipart 

segment on object-oriented design, I’m now 

going to take a look at the task of “gathering 

requirements.” This process in a development project can 

be labeled many things, and you might typically hear it 

called “requirements analysis,” “the analysis phase,” 

“specification construction,” or any number of variants. 

For the remainder of this column, I’ll simply use the term 

“analysis” to refer to the process of determining what the 

problem at hand is and what needs to be developed to 

solve that problem. In the world of object-orientation, 

this is a sub-field all its own, typically referred to as 

“object-oriented analysis.” Covering all the different 

concepts and ideas associated with object-oriented 

analysis is well beyond what can be covered in a single 

article, but I’ll list a couple of good references for those 

who are interested in learning more. While much of my 

own experience and focus these days is on object-oriented 

development, you might notice that not every item on 

this particular checklist is specific only to object-oriented 

projects. In fact, a number of the checklist items are 

applicable to nearly every software project, regardless 

of its development language, size, or cost. 

So, what exactly is “analysis”? Working backwards 

in the lifecycle of a software project, the “coding” is 

the process of implementing a software solution. The 

“design” phase of a project is used to determine how the 

system should be built (which parts it will contain and 

how they work together to form the system). The 

“analysis” phase, however, is the process of determining 

what needs to be built. In other words, an analysis process 

is meant to figure out the scope of the problem that the 

software must solve. I like to think of it as a process of 

“putting limits on the project” because the analysis phase, 

more than any other, will determine the scope of what the 

Best Practices FoxTalk 

system will (and won’t) do. 

Like any other process, the analysis phase of a project 

needs to have a result or end product. Typically, this will 

come in the form of a “requirements specification” that 

details what the system is expected to do. The form of 

these specifications can vary from project to project, 

depending on project size and a variety of other factors, 

but it might consist of a three-page narrative describing 

the system or a multi-binder set of diagrams, tables, and 

plain-English text. It’s difficult to know in advance when 

enough requirements information has been gathered, but 

you’ll definitely know it after the fact. If the developers 

working on the design phase of a project keep going back 

to the clients (or others involved in the analysis) for more 

information or clarification, then you know that the 

specification could have been more complete. 

With these ideas and definitions out of the way, 

let’s get started on the checklist of issues to watch out 

for during this early phase of a project. 

Is a true “analysis effort” being made 

at the start of the project? 

Yes, I know it sounds incredibly obvious to bring this up, 

but many projects get started with someone sitting down 

to write code and “prototype” the application in advance. 

It’s important that everyone involved with the project be 

aware of the importance of doing the analysis and 

gathering requirements. Even the smallest of software 

applications is intended to solve some sort of problem, so 

make sure there’s a clear understanding of what that 

problem is before beginning any design or coding effort. 

This can save a lot of embarrassment, headache, and, 

most importantly, money by avoiding situations wherein 

a certain “something” gets developed that isn’t at all the 

“something” that the end-users truly need. 

Unfortunately, some management types have the 

impression that a software developer can just sit down, 

close the door, push a few buttons, and magically deliver 

the software that management sees in their heads. There 

isn’t always a lot you can do to convince these people 

otherwise, but you can try to get the eventual users of the 

software involved early to make it clear that some form of 

requirements gathering needs to be performed. These are 

the people who will likely be “living with” your software 



6.0

on a daily basis and, presumably, will have their jobs 

made easier through your efforts. They naturally have 

a vested interest in making sure the developer(s) 

completely understands the problem domain that the 

software will address. Their involvement will make it 

clear to management that it’s important for you to have 

as much clarity as possible when it comes to the true 

goals of the software. 

Are all of the necessary people being involved to 

define the system’s intent and requirements? 

In light of the preceding section, it’s important to realize 

that it really takes a variety of people, at a variety of 

organizational levels, to make a software project 

successfully meet the needs for which it’s intended. 

Typically, you’ll have the management types who approve 

the project and ultimately compensate you for your work. 

Whether you’re a corporate developer or an independent 

consultant makes no difference other than the name that 

appears at the top of everyone’s paychecks. Since these 

are the people paying you, you want to make sure they’re 

involved, happy, and see progress happening. As I’ve 

already mentioned, you also need the end-users to be 

represented in the analysis phase because they’re going to 

be putting the fruits of your labor to work. While these 

people probably don’t approve your compensation, I tend 

to think they’re more important to the developer than the 

management type. That’s because they’re likely to be 

vocal when it comes to judging the results of your work. 

A manager who’s happy with your efforts isn’t likely to 

stay that way if he’s got an end-user mutiny on his hands. 

The point here is that it’s important for both types of 

people to be involved. While the end-users can ultimately 

tell you what needs to be done, the managers must be 

involved to tell you the constraints within which it must 

be done (budgets, schedules, and so forth). 

If possible, try to get feedback from more than just 

one “future end-user” for your system. If you’re getting 

all of your requirements and input from one person, you 

run the risk of developing software that meets the needs 

of the way that one person works. This can come at the 

expense of everyone else who must use the system, 

many of whom may have different needs or methods for 

approaching their job. Where I work, we write software 

applications for a wide variety of clients in the energy 

industry and ship that software with large volumes of 

data. The purpose of our software is to give the users a 

variety of tools and mechanisms for interpreting the 

data that they’ve licensed. One of our internal product 

managers will often come up with a variety of new ideas 

and functionality for his product and then explain to me 

that he’s “the typical end-user” for that product. Much as 

I wish he were “typical,” he’s significantly more familiar 

with the energy industry and our data than any “typical 

end-user” is, and that has to be factored into any requests 

or suggestions he makes. The point I’m hoping to make 

here is that it’s important to “know the audience” for 

your software application. With the input of only a small 

cross-section of the potential user base, you run the risk of 

developing software that meets the needs and desires of 

the few—at the expense of the many. 

Another point that’s worth making concerns other 

developers. If possible, get the people who will be doing 

the system design and implementation involved with the 

analysis effort. While it’s nice to have so complete a 

specification that it can be handed with confidence to a 

designer who wasn’t involved with that process, having 

other developers there can add clarity in the later phases 

of the project. They might ask different questions than the 

person assigned the requirements responsibility, and 

asking questions is the analysis phase. 

Has a common vocabulary been defined 

for developers and users so they can 

clearly communicate? 

Every type of business and job function has its own 

language. As a software developer, it’s likely that you’ll be 

exposed to a wide variety of businesses and industries. 

Personally, I know that’s one of the most exciting aspects 

of software development for me. As you get into each new 

project, however, you’re probably going to hear a variety 

of new terms and even some old terms that have 

meanings other than the definition you’re familiar with. 

As you’re meeting with the other parties involved with 

the project, make sure to stop and get definitions and 

explanations whenever they refer to something that 

you’re not clear on. It’s pretty common for this process to 

begin with someone saying, “Let’s start with the basics,” 

as they proceed to give you the background information 

they think you need. If you’re not completely clear on that 

background information, you’re really going to be lost 

when they get to the explanation of their problem. Once 

again, the point of an analysis effort is to get questions 

answered, so make sure to ask them early. Having a 

shared vocabulary established early in the process will 

make all communications much easier throughout the life 

of the project. 

This is also a good time to point out the importance 

of remembering that not everyone you’re working with 

in this phase of a project is a software developer. Terms 

like “inheritance,” “encapsulation,” and “referential 

integrity” might be commonplace in this newsletter and 

at programming conferences, but they don’t mean a 

thing to your average computer user or business 

manager. Because this phase of a project is primarily 

for the end-users, try to keep the development-related 

technical jargon to a minimum and speak to them in 

their language. You can translate their needs and desires 

into your programming terms in the design phase of 

the project. 


7

Is a completely different approach being forced 

on the eventual users of the system? 

The typical goal of a software project is to accurately 

model some process that the end-users would otherwise 

have to go through manually so that their job is ultimately 

made easier. The chances are pretty good that these endusers 

are already performing the task that the software 

will model, and they’re used to doing it in a certain way 

or using a specific methodology (perhaps even with an 

existing software application). As the analysis phase of a 

project begins, it’s not uncommon for users to come up 

with new ways of approaching their job, sometimes at the 

suggestion of the developer gathering the requirements 

(no hidden motives there, huh?). When the analysis of 

the new system begins to look like a completely new 

approach for the business process, proceed very carefully. 

As much as I hate to borrow an incredibly over-used 

term, what you’re watching out for here is a “paradigm 

shift” in the approach the software takes to solve the 

business problem. 

I should clarify that this caveat isn’t intended to stifle 

anyone’s innovation or creativity. I think that users are 

generally excited by being a part of the requirements 

gathering process, and it’s easy for them to lose sight of 

the fact that this software will likely become either a very 

good friend or another drudgery added to their day. If the 

approach the software uses to solve a problem isn’t a 

sound or “tried and true” approach that the users can 

work with, they’re not going to be happy once the system 

is deployed and the “honeymoon period” is over. The one 

area that I think is a slight exception to this rule is when a 

shift will mean a large increase in the user’s efficiency. 

Anyone can get used to something that makes their day 

easier or frees up more of their time, but make sure that 

changing the “business process” isn’t going to ultimately 

have the opposite effect. Innovate where it makes sense, 

but don’t change things on the user purely for the sake 

of change. 

Have all of the necessary—as well as potentially 

new—components of the system been discussed? 

With some projects, you’ll be writing a system that 

replaces an older, obsolete, or possibly cumbersome 

system that’s already in place. Other times, you’ll be 

creating an application from scratch to streamline an 

existing business process. In the latter case, the users and 

their managers might not have any idea what they need 

or could use until you come right out and suggest it. In 

the former case, they might be so used to dealing with the 

existing software that they don’t see past it for new ideas 

and functionality. For that reason, I’m using this checklist 

item as a catch-all to list the types of things you might 

suggest to them. These are components that appear in 

many different types of applications and might or might 

not be important for any given project. 

For starters, do they have any existing reports, 

spreadsheets, or documents that the system will need to 

be capable of generating or reading? If there’s already a 

system in place, should the existing data be converted to 

a new format, or should it simply be archived so they 

can start fresh? Should the application have any security 

mechanisms built into it and, if so, to what degree? Now 

that everyone and their pet has an e-mail address, should 

the application be capable of sending (or even receiving) 

e-mail messages? Is there a need for users to do offline 

work with their data, separated from the primary data 

sources? Could they use remote access capabilities in 

the application? Do they have a need for specific file 

structures or file types? Will the system need to have 

any export or import capabilities? Does the system need 

backup functionality built into it, or will they use some 

other backup solution? How much flexibility do they 

need for customizing the user interface or business 

logic within the system? Do they need access to file 

maintenance capabilities in the system, or should those 

be handled automatically? To what extent should the 

system provide online help or user assistance? Should 

the help system only aid them with the use of the system, 

or should it also provide assistance with the business 

process that the system is designed to model? 

Obviously, there are a lot of these types of questions 

to be asked when you sit down to work out the 

requirements for a new software application. Trying to 

come up with an exhaustive list would be impossible for 

me to do here, but the preceding suggestions should give 

you some ideas of the types of things that might not occur 

to users until they’re suggested. Going on the assumption 

that you want this application to be as useful as possible 

for your end-users, ask lots of questions and make sure 

you’re clear enough on the answers to meet their needs 

with a true solution. 

Has the specification been built with scalability 

and future expandability in mind? 

An application that can “scale up” as the needs placed on 

it grow must be intended that way from the onset. While 

it’s usually an interesting “employee interview” question, 

you might find it useful to find out where the users and 

buyers of this system expect themselves and the software to 

be in a couple of years. You might be writing a small, 

standalone sales system for a bookstore today, but what if 

they plan to grow into a new space next year and have 

three different sales computers? Most businesses have 

growth as a primary goal, so it’s important to find out 

how much expansion capability the users and managers 

would like to see. Chances are that your software will 

need to be replaced if they become the next “Barnes & 

Noble” or “Amazon.com,” but you don’t want it to be 

obsolete as soon as they need a little more storage 

capability either. 

I should note here that I’m not referring specifically to 

the software’s internal flexibility and expandability. That 



comes as a function of the design phase in the project and 

should be built into every system you work on. Even if 

the business never grows, the needs of the software might 

simply change, and it’s important to have that capability 

inherent in the components of the application. Instead, 

this topic is intended to get you thinking about the actual 

growth that a system might undergo. For example, you 

might write a relatively simple application for a small 

business that doesn’t have any networking or multi-user 

needs at all. One day, the owner calls you and says he’d 

like to be able to access the software from home so that he 

doesn’t have to go into the office every day. That’s easy 

enough, but he’d like to be able to do that even if one of 

his employees is in the office and using the system. 

Suddenly that simple application you built needs remote 

access and multi-user capabilities. A year later, the owner 

calls you and tells you he needs the software to be 

running around the clock with zero downtime, but he also 

wants nightly backups made of all that data in the 

background. Now it makes more sense for the Visual 

FoxPro application you built to be using SQL Server as a 

back-end instead of native VFP tables. Suddenly all the 

data-related code you wrote won’t do, and you wish 

you’d been using view definitions from the beginning. 

Once again, these are issues that can be resolved with a 

solid application design effort, but it’s good to get them 

out in the open during the analysis phase, if only to get 

feedback and suggestions from the true “owners” of 

the system. 

Have all “use cases” and “actors” that 

might be required within the system 

been discussed and clarified? 

In his book Object-Oriented Software Engineering: A Use 

Case Driven Approach (Addison-Wesley, ISBN 0201544350), 

Ivar Jacobson discusses the idea of using “use cases” and 

“actors” to work out the requirements of an objectoriented 

application. A “use case” is roughly defined as a 

description of the tasks that must be completed as part of 

an overall process. For example, an automated teller 

machine might have a “withdraw cash” use case, a 

“deposit check” use case, and a “balance inquiry” use 

case. On its own, the description of a use case doesn’t 

have much value other than to provide a convenient way 

to refer to a larger process or series of steps. An “actor” is 

described as an “external agent” or “user” involved with 

the process that a use case describes. For example, a 

purchasing system for a company might have a “fulfill 

order” use case as one of its needs. The steps involved 

with this process might include an employee filling out a 

request form, a supervisor approving the request, a 

purchaser making the purchase, a supplier providing the 

requested materials, and a mailroom employee delivering 

it. Each of these persons is considered an “actor” within 

the “fulfill order” use case because the process isn’t 

complete until each of them has performed his or her role. 

My goal here isn’t to convince you that Jacobson’s 

approach is the best or only way to go for your own 

analysis, though I do highly recommend his book. 

Instead, it’s to provide you with an additional way to 

determine whether or not all the questions have been 

asked when analyzing the needs of a system. In truth, I 

have to agree with the author of another excellent book— 

Object-Oriented Software Construction, Second Edition by 

Bertrand Meyer (Prentice Hall, ISBN 0136291554)—in 

suggesting that unless a development team has plenty of 

experience developing object-oriented applications, the 

use case approach can be somewhat limiting during the 

analysis and design phases of a project. As Meyer points 

out, the use case approach requires that the process be 

described in a fairly rigid fashion with a specific sequence 

of events. This can be at odds with the abstract, stateless 

approach that an object-oriented application should 

take—an approach where various self-contained objects 

can receive a type of request and proceed to work in 

conjunction with other objects as necessary to meet that 

request. As such, I don’t believe that a use case approach 

should be the only method of determining the needs of an 

object-oriented application. I do, however, think that use 

cases can be a valuable tool for looking at a system’s 

requirements from a new and unique perspective. When 

taking the time to describe a system as a series of use 

cases, each of which requires a set of actors for 

completion, you might find that an important 

requirement or consideration has been overlooked. 

Are there clear limits to what the system 

will and won’t do when complete? 

Here’s another seemingly obvious item that I think is 

often overlooked in requirements gathering efforts. It’s 

common for the analysis to indicate everything that an 

application should do, but much less common is for some 

attention to be devoted to what it shouldn’t do when 

complete. For example, if your application must have an 

option to let the user export a table to another file format, 

should the user also have the ability to choose which 

fields in the table are exported? If the application has a 

charting or graphing component, will it also have the 

ability to export the chart as a graphic file? 

When the developers working on the design effort get 

the results of the analysis phase, they’re naturally going to 

have questions about the extent to which they should 

account for the unknown. When possible, indicating what 

the application doesn’t need to do can help them rule out 

some of those unknowns and focus more clearly on the 

things that the application does need. 

Is there an end result to all of the analysis 

and requirements work? 

A requirements effort is really only as good as the 

specifications and documentation it generates at the 

end of the process. Getting a variety of people involved, 


9

combining opinions for a consensus, and determining 

every last need for a software project is great, but it’s 

useless without some way of communicating those 

results to the people who will design and implement 

the solution. 

As I mentioned earlier in this column, the end result 

for an analysis effort could be anything from a free-form 

memo that’s a few pages in length to a truckload of 

documentation that details every last need in the finest 

level of detail. Where your needs fall within those 

extremes should be determined early in the analysis 

phase so that everyone knows going in what’s expected at 

the end of the process. Make sure that the specifications 

are provided in writing and don’t consist of a 

“specification meeting” with the people who will 

design and implement the system. Invariably, intents 

and desires will be left out of a meeting format, and the 

miscommunications that result can be the death of a 

software project. 

Have all the necessary people approved 

the final analysis results? 

Once you’ve got the requirements put together and put in 

writing, make sure that everyone who has an interest in 

the project has “signed off” on the results. This doesn’t 

need to be a formalized process with people signing their 

lives away, but they should have an opportunity to review 

and make comments on the results of the process they’re 

involved in. 

Getting the results of the process approved by 

everyone greatly increases the chance of success for a 

project because it avoids the “it does what I said, but not 

what I meant” problem that often pops up during a 

project. When someone reads through the description of 

their needs later, well after they initially expressed those 

desires, they can often clarify those thoughts so that what 

they’re agreeing to is truly what they want. Having 

management review the requirements will ensure that the 

system requirements are in line with the goals of the 

business, and having the end-users take part in the review 

will make sure that the application will truly be of use to 

them in their job functions. In short, it’s just a matter of 

making sure that everyone with a vested interest in the 

project is on the same page. Your development staff 

thanks you for this. Trust me. 

Wrap it up 

That brings to a close my list of items to watch out for 

during the analysis, or requirements gathering, phase of a 

software project. I know it’s by no means an exhaustive 

list, but I hope it triggers a variety of new ideas and 

checklist topics for you to use on your own. As always, 

feel free to send me your feedback and thoughts on this 

(or any other) topic, as well as your suggestions for future 

checklists or columns. 

If you’re interested in reading some more in-depth 

discussions of the analysis phase, I highly recommend 

each of the books I’ve mentioned in this column. And 

speaking of great books, I finally got around to finishing 

What Every Programmer Should Know About Object-Oriented 

Design by Meilir Page-Jones (Dorset House, ISBN 

0932633315). Right there at the end of the book, in 

Appendix A, was an exhaustive checklist of 51 things to 

watch for during an object-oriented design. If you were 

left hungry for more ideas or in-depth discussion after the 

object-oriented design checklists I presented over the past 

two months, I’d definitely recommend this book. It’s 

written in a very readable, light style and covers the 

design phase of a project in great detail. It just occurred 

to me that, while my last couple of columns might or 

might not have provided any additional food for thought, 

they could have inadvertently blown your budget for 

“development books.” I should probably stop here and 

give some thought to making next month’s column the 

kick-off for a new 12-step program for book addicts like 

myself. See you then! ▲ 

Jefferey A. Donnici is an applications developer who specializes in 

reusability and design issues with Resource Data International, Inc. in 

Boulder, CO. Jeff is a Microsoft Certified Professional in Visual FoxPro 

and a three-time Microsoft Developer Most Valuable Professional. 

303-444-7788, fax 303-444-1286, jdonnici@compuserve.com, 

jdonnici@resdata.com. 



Traversing Transactions 

Jim Booth 

Last month, Jim discussed TableUpdate() and TableRevert() 

and showed how they enable you to control updates while 

using buffering on your cursors and tables. These two 

functions are really very good for handling the updating or 

reverting of a single table or cursor. This begs the question, 

“How can I coordinate the updates or reverts to a number of 

related tables?” Gary DeWitt discussed transactions in the 

January and March 1998 issues of FoxTalk in preparation for 

MTS; this month, Jim reviews that and discusses what can fail 

during a transaction. 

THERE are situations where you need to update more 

than one table or cursor, and the combination of the 

updates represents one action on the database. This 

action has to be an “all or none” operation—that is, either 

all of it happens or none of it happens. For example, in 

writing the code to save a new invoice, you need to add 

a record to the invoice header table, add a group of 

records to the invoice line item table, update the balance 

in the customer record, and add a record to the accounts 

receivable table. If any of these operations fail, you’ll need 

to reverse the earlier ones that did succeed and make sure 

that none of these updates get into the data. Transactions 

are designed for this very purpose. 

You use the BEGIN TRANSACTION command to 

start the transaction tracking in Visual FoxPro, and the 

ENDTRANSACTION command to complete the 

transaction or the ROLLBACK command to reverse 

the transaction. 

How do transactions work? 

When VFP encounters a BEGIN TRANSACTION, it starts 

to track the file update operations that occur. For each 

update action, VFP secures the required locks, but it 

doesn’t do the update yet. When an ENDTRANSACTION 

is encountered, VFP then does all of the file writes 

involved in the transaction and releases the locks that 

were obtained. If a ROLLBACK command is encountered, 

VFP will release the locks without doing any of the file 

write operations. 

Through this process, VFP is able to assure that either 

all of the file updates are done or none of them are done. 

It’s a very good idea to keep the BEGIN TRANSACTION 

and ENDTRANSACTION/ROLLBACK commands as 

physically close to each other in the code as possible. 

Doing this reduces the period of time that the resources 

are locked. 

What’s Really Inside FoxTalk 

Which tables and cursors 

can participate in a transaction? 

Transactions in VFP are only available for tables that are 

in a database (DBC). Free tables can’t participate in a 

transaction, and a rollback or other abnormal end of the 

transaction doesn’t affect any updates made to free tables 

during a transaction. 

This can cause some interesting effects if a free table is 

the source of data for a local view that’s managed by a 

transaction. I’ll examine the steps in the process of a 

fictitious transaction—in this transaction, there’s one table 

in a database named Table1 and a view named View1 that 

gets its data from a free table named Table2. Here’s the 

code for the transaction: 

BEGIN TRANSACTION 

IF TableUpdate( 1, .F., "View1") 

IF TableUpdate ( 1, .F., "Table1") 

END TRANSACTION 

ELSE 

ROLLBACK 

ENDIF 

ELSE 

ROLLBACK 

ENDIF 

If the TableUpdate for Table1 fails, will the 

ROLLBACK undo the changes to View1 and set it back to 

its state prior to the transaction? Yes, it will roll back the 

changes to View1. Will the changes to Table2 that were a 

result of updating View1 be reversed by the ROLLBACK? 

No, because Table2 is a free table and therefore isn’t 

participating in the transaction. This can leave your data 

in an undefined state, so you have to manage the free 

table yourself. It’s best not to depend on transactions 

when free tables are involved in any way. 

Show us the code! 

How do you integrate transactions into your forms? It 

can be done on a form-by-form basis, or you can do it 

generically in a form class. The following is some 

pseudo-code that will give you the outline of the structure 

for incorporating transactions into your updates. 

* Set a variable for tracking a failure. 

LOCAL llRollBack 

llRollBack = .F. 

* Wait until all data processing is complete 

* before beginning the transaction. 

BEGIN TRANSACTION 

* Now do each update checking the result. 

IF NOT TableUpdate( … ) 

llRollBack = .T. 

ELSE 



11

Transactions: Tahoe and 

Microsoft Transaction Server 

Gary DeWitt 

Component reuse is one of the key goals of object-oriented 

programming and one of the difficulties with transaction 

processing—until now. Here’s how Tahoe and Microsoft 

Transaction Server can work together to create and deploy 

robust, reusable transactional components. 

AT the First National Bank of Dad, the CFO, Dad, 

has realized he can no longer give his account 

holders personalized service. Instead, he’ll install 

an ATM (automatic teller machine) to handle the everincreasing 

demand for the bank’s services. The ATM must 

allow a depositor to deposit his or her allowance into 

savings or checking accounts, withdraw allowance from 

either account, and transfer allowance from one account 

to the other. 

In the January 1998 issue of FoxTalk (see 

“Transactions: Take the ACID Test”), I introduced you to 

transaction processing at the First National Bank of Dad. I 

described an account object with two methods: Deposit() 

and Withdraw(). Each of these methods uses transactions 

to ensure that the database is updated correctly. The 

transaction is started and ended within the context of a 

deposit or a withdrawal. 

In the March 1998 issue of FoxTalk (see “Transactions: 

Keeping Them in Context”), I discussed ways that the 

account class can be written so that it can work in the 

context of a funds transfer, where both a deposit into one 

account and a simultaneous withdrawal from another 

account must both succeed or both be rolled back. You 

learned about nested transactions and the often 

complicated ways of writing components to work in the 

context of other transactions. Writing robust, reusable 

transactional components for client/server databases 

can be particularly difficult. I ended by wishing for a 

better way. 

A better way 

Warning: You need to know this stuff. The techniques I 

discuss in this article are applicable to client/server 

databases, but there are some key events on the horizon 

that are likely to make you want to do more client/server 

applications, even for desktop deployment. 

I recently visited Microsoft’s Web site (http:// 

www.microsoft.com) and executed a search on the phrase 

FoxTalk 

“SQL Server 7.” I found numerous Web pages, 

presentations, and press releases about the next version 

of Microsoft SQL Server, code-named Sphinx. One of the 

key features I found for SQL Server 7 is scalability. Not 

only will it scale to very large databases, but to very small 

ones too. One PowerPoint presentation on the Microsoft 

site called this “SQL Desktop” and “Embeddable SQL.” 

According to Microsoft, SQL Server 7 will run under both 

Windows NT and Windows 9x. The embedded version 

will have a small footprint, and you’ll be able to distribute 

it with your applications to run on desktop systems and 

even laptops. It will finally be not only desirable, but 

also possible to use SQL Server for small database 

applications. 

The other key event is the release of Tahoe. Tahoe 

allows you to write components that take full advantage 

of MTS (Microsoft Transaction Server) and Microsoft 

SQL Server. 

What is MTS? 

MTS, currently in version 2.0, is a powerful environment 

that makes it easier to develop and deploy robust, highperformance 

transactional components. Last September at 

the Visual FoxPro DevCon, Microsoft demonstrated some 

of the new features of Tahoe, including its ability to work 

with MTS. I was so excited about the possibilities that I 

rushed home and immediately started experimenting 

with MTS 1.0, SQL Server 6.5, and Visual Basic 5.0. As I 

write this (in early April), I’ve been working with MTS 

2.0, SQL Server 6.5, and Tahoe nearly every day for 

about a month. 

Here are some of the advantages I’ve discovered 

from using this combination of tools: Well-written 

components can be reused in any transactional context 

with no modifications; valuable resources, such as ODBC 

connections, can be pooled with no modifications; granular, 

easy-to-develop components can be combined with no 

modifications; complicated distributed transactions can be 

implemented as easily as simple ones with no modifications; 

performance of frequently used components can be 

enhanced with no modifications. 

At the risk of being accused of belaboring my point, 

let me reiterate that all these advantages can be achieved 

in components written for MTS with no modifications. 



6.0

Basic MTS transactional components 

MTS components you create with Tahoe are in-process 

servers. Unlike other in-process servers, these run in a 

Transaction Server process, rather than your application’s 

process. MTS assigns transactional components a 

transaction context. Your components can get an object 

reference to the transaction context by using one of the 

MTS ActiveX servers. 

*-- Obtain a reference to transaction context. 

oServer = CREATEOBJECT("MTXaS.Appserver.1") 

oContext = oServer.GetObjectContext() 

The context object is used to commit or roll back 

transactions. Commit a transaction by calling the context 

object’s SetComplete() method: 

oContext.SetComplete() 

Roll back a transaction by calling the context object’s 

SetAbort() method: 

oContext.SetAbort() 

That’s it. That’s all you have to do to write a 

transactional component. Use the exact same technique 

for all transactional components with no modifications. 

How does it work? MTS creates a new transaction 

context for a new transactional component. In this case, 

GetObjectContext() returns a reference to the new 

transaction context. But if one transactional component 

creates an instance of another transactional component, 

then GetObjectContext() returns a reference to the original 

object’s context. How do you know which is which? You 

don’t. It doesn’t matter. If any method in a transaction 

calls the context object’s SetAbort() method, then the 

transaction will be rolled back. The component calling 

SetAbort() doesn’t need to know whether it has its own 

transaction or is part of another component’s transaction. 

The code runs the same either way. 

In the first two articles in this series, I created an 

account class with Deposit() and Withdraw() methods. 

Both called the Post() method, Deposit() passing the 

amount as a positive number, and Withdraw() passing it 

as a negative number. The Post() method fails if the new 

balance in the account is less than zero. Let me create 

a new, simplified Post() method using MTS. For the 

purposes of this simple example, assume I have a 

remote view of the account table. I also have three 

constants for return values: ERROR_SUCCESS, 

ERROR_OVERDRAWN, and ERROR_OTHER. First I get 

a reference to the object context and open the database 

and the remote view: 

LPARAMETERS nAccountNo, nAmount 




*-- Open database and view. 

OPEN DATABASE Test 

USE Account 

In the next step, I add the amount of the transaction 

to the balance in the account. Note that in a withdrawal, 

nAmount would be a negative number: 

*-- Attempt to post the amount to the account. 

REPLACE balance WITH balance + nAmount 

Here’s where all the decisions are made: 

IF balance < 0 

*-- Insufficient funds, roll back. 


nSuccess = ERROR_OVERDRAWN 

ELSE 

*-- Sufficient funds, attempt to update. 

IF TABLEUPDATE(2, .T.) 

*-- Update successful. 


nSuccess = ERROR_SUCCESS 

ELSE 

*-- Update failed. 


nSuccess = ERROR_OTHER 

ENDIF 

ENDIF 

The first thing to check is whether or not there are 

sufficient funds for the transaction. If the balance is less 

than zero, the account would be overdrawn. Such a 

condition isn’t allowed, so I abort the transaction by 

calling SetAbort() and set the return value to my constant 

that indicates an overdraft. 

If no overdraft condition exists, I attempt to update 

the database with TABLEUPDATE(). If it succeeds, all is 

well and the transaction can be committed and the return 

value set to the constant indicating success. If the update 

fails, there’s some other problem. In this example, rather 

than dealing with the myriad reasons why an update 

could fail, I simply abort the transaction and set the return 

value to the constant indicating a problem. 

All that remains now is to clean up after the 

transaction and return the value: 

CLOSE DATABASES ALL 

RETURN nSuccess 

When the account component is added to an MTS 

package and used, the Post() method can be used to 

manage deposits and withdrawals. The Transaction 

Monitor in the Transaction Server Explorer can be used to 

track the number of transactions attempted along with the 

number of active transactions, the number of successful 

transactions, and the number of aborted transactions. 

Managing resources 

I see some hands going up right now—people who want 

to know why I open the database and the view without 

checking to see whether they’re already open and why I 

close everything at the end rather than leaving them open 

for future use. Good question. 

Without MTS, I’d have to write plenty of code to 

ensure that I’m not clashing with already-opened views. I 

also wouldn’t want to close everything as soon as I’m 

done with it. After all, opening a remote view requires 

that VFP load the ODBC manager, driver manager, and 


13

driver DLLs and open an ODBC connection to the 

database. Without MTS, I’d want to keep a connection 

open so that VFP doesn’t have to do all that work every 

time you call a method. 

MTS keeps DLLs in memory for a while after they’re 

no longer used. It also pools ODBC connections. If an 

object uses a connection, MTS keeps it open so that other 

objects can use the same connection. In this way, MTS 

can improve the performance of future requests for an 

object and can reduce the number of ODBC connections 

required. Remember that in client/server databases, more 

connections often means paying higher licensing fees and 

a higher requirement for resources. 

Transaction Server’s resource pooling, combined with 

Tahoe’s new apartment-model threading, provides some 

phenomenal performance improvements. I’ve conducted 

comparisons between components created and run in VFP 

5.0 and those created with Tahoe and run in Tahoe and 

MTS, and I’ve seen performance improvements of over 

100-fold when creating multiple instances of transactional 

components! 

To take advantage of resource pooling, I subclass all 

my transactional components from VFP Forms. Forms 

can have private datasessions so that multiple instances 

of in-process servers don’t step on the toes of other 

instances. If you do this, be sure you remember to make 

the appropriate environment settings. I can’t tell you how 

many times I’ve elevated my blood pressure by forgetting 

to SET EXCLUSIVE OFF in a component and received an 

OLE error (worse yet, with beta versions of these tools, I 

became an expert at causing GPFs). I’ll talk more about 

resource pooling later in this article. 

The promise comes true 

For several months now, I’ve been promising to show you 

how to easily reuse transactional components. MTS makes 

the promise come true. As I’ve shown with the account 

object, individual MTS transactional components never 

need to know their context. New components can be 

created that combine existing components into new 

transactions. The First National Bank of Dad will use an 

ATM component that can combine the Deposit() and 

Withdraw() methods of the existing account component to 

transfer allowance from one account to another with no 

modification to the account component. 

To do this, the Transfer() method of the ATM 

component uses the CreateInstance() method of its MTS 

context object to create each instance of the account 

component. 




*-- Create an instance of account component. 

oAcct = oContext.CreateInstance("acct.account") 

When you create an instance of the account 

component with CreateInstance() instead of 

CREATEOBJECT(), you ensure that the account object 

inherits the transaction context of the calling object. The 

account component doesn’t need to know this, however. 

It knows how to get a reference to the transaction context; 

MTS takes care of the rest. 

Here’s what the Transfer() method of the ATM 

component looks like: 






nSuccess = oAcct.Deposit(nAccount1, nAmount) 

IF nSuccess = ERROR_SUCCESS 



nSuccess = oAcct.Withdraw(nAccount2, nAmount) 

IF nSuccess = ERROR_SUCCESS 

*-- Deposit and withdrawal successful. 


ELSE 

*-- Withdrawal failed. 


ELSE 

*-- Deposit failed. 


ENDIF 

What’s going on here? First, remember that the 

Deposit() and Withdraw() methods of the account 

component simply call the Post() method after ensuring 

that the amount is positive for deposits and negative for 

withdrawals. Otherwise, the account component is being 

used unchanged in a new context. Notice that I deposit 

money in one account before withdrawing from the other. 

I did this deliberately to illustrate the point that it makes 

no difference what order components are used. If one 

method calls SetAbort(), then everything fails and is 

rolled back together. After running this code a few times, 

I firmly believe in magic. 

More on resources 

A few more hands have gone up. Why, you ask, did I 

create two instances of the account object—using the 

same reference memvar, no less—rather than reuse the 

same instance? 

One of the side effects of using a context object’s 

SetComplete() or SetAbort() method is that MTS will 

release the object as soon as the method calling 

SetComplete() or SetAbort() ends. This is what might be 

termed the MTS garbage collection. In the case of the 

account component, its resources are freed up as soon 

as the call to Deposit() or Withdraw() returns. The 

disadvantage to this is that you have to create another 

instance when you want to call another method. But 

there’s an advantage, too: MTS frees resources sooner, 

so they can be used again. 

Here’s an example of the account component’s 

GetBalance() method. Note that it makes no changes to 

the database, but calls SetComplete() anyway to ensure 




Use the Microsoft Scripting 

Control to Script with VFP 

Rod Paddock 

Have you ever wanted to add a programming language to 

your Visual FoxPro applications? If you answered yes, you’ve 

come to the right place. Microsoft has released an ActiveX 

control for adding programming languages to your VFP 

applications—the Microsoft scripting control. 

VISUAL FoxPro supports two constructs for adding 

custom scripting to your applications. You can use 

Macro expansion—the & operator—or the EVAL() 

function. The problem with these constructs is they limit 

you to using simple commands and expressions. You can’t 

use control structures like IF/ENDIF, DO/LOOP, FOR/ 

NEXT, or calling subroutines. This is where VFP’s native 

capabilities end and the advantages of the scripting 

control begins. 

Where to find the Microsoft scripting control 

The first step in using the Microsoft scripting control 

is to download and install it—it can be found at 

www.microsoft.com/scripting. Once you’ve installed the 

scripting control, add an instance of the control to a form, 

and get ready to rock. 

A quick note about a great utility . . . 

A utility program called CodeBlock by Randy Pearson 

was created a few years ago to address the limitation of 

combining macro expansion capabilities with looping 

constructs like DO WHILE and FOR/NEXT loops. 

Essentially, Randy built a runtime interpreter for FoxPro. 

With the exception of those commands that aren’t allowed 

outside the FoxPro IDE—such as COMPILE—just about 

any other block of code is allowed. The program allows 

you to store code in memo fields—and have that code 

executed on an interpreted basis—as if it were compiled. 

So if you have FoxPro or VFP applications that you’d like 

to equip with this capability, check out CodeBlock. A copy 

is included in this month’s Subscriber Downloads at 

www.pinpub.com/foxtalk. 

However, if you’re interested in adding new language 

capabilities like VBScript or JavaScript to your VFP 

applications, then read on. (Tip: If you’re interested in 

acquiring a VBScript reference, take a look at this URL: 

http://www.microsoft.com/scripting/default.htm?/ 

FoxTalk 

scripting/vbscript/default.h. Or, if you already own 

Visual Studio, take a look at the Help files that come 

with Visual Interdev—it includes VBScript and 

JavaScript references.) 

Scripting control basics 

Using the scripting control in its basic form only requires 

four steps: 

1. Add an instance to a form. 

2. Set the language property. Your choices of languages 

are VBScript or JScript. 

3. Add the code you want to execute to the control using 

the AddCode method. 

4. Execute the code using the Execute Statement method 

of the control. 

The following code creates a basic message box 

function using VBScript: 

#DEFINE CRLF chr(10) + chr(13) 

*-- Set the language 

Thisform.oleScriptingControl.Language = "VBScript" 

*-- Add a function 

Thisform.oleScriptingControl.AddCode([Function Test] ; 

+ CRLF + [msgbox "hello"] ; 

+ CRLF + [ End Function ]) 

*-- Execute the function 

Thisform.oleScriptingControl.ExecuteStatement("Test") 

That seems pretty straightforward, doesn’t it? Here’s 

how the code works: The first step to using the scripting 

control is to set the controls language property. You have 

two choices: VBScript and JScript. If you specify the 

language property as VBScript, the code you add with the 

AddCode method must be VBScript (a subset of Visual 

Basic for Applications). If you specify JScript, the code 

added must be in JavaScript. 

Next, use the AddCode method to load the control 

with source code to execute. The AddCode method 

accepts one parameter: a string that contains multiple 

lines of code delimited by CR+LF characters. 

Finally, run your code using either the Run or 

ExecuteStatement methods. The Run method executes 

functions or subroutines. The ExecuteStatement method 


15

executes a single statement (like “x = 1”) or a simple call 

to a function. There’s one aspect of this method that’s 

rather tedious—the requirement for you to code manually, 

delimiting each programming line with CR+LF sequences. 

As a result, wouldn’t it be convenient to have a 

mechanism similar to the VFP command window? I 

thought so, so I created a Scripting Control testbed. 

Figure 1 displays my Visual Basic command window 

style interface. 

Manipulating FoxPro objects with VBScript 

Now for something really cool. One of the most powerful 

aspects of the scripting control is its ability to manipulate 

VFP (or Visual Basic) native objects. Calling the 

AddObject method of the scripting control does this. Yes, 

the scripting control has a method called AddObject, so 

you can add an object to the scripting object container. 

The syntax for this method consists of two parameters. 

The first is the name that the object will be referenced by 

in your VBScript or JScript code. The second parameter is 

a handle to your object. 

To add a form to the scripting control, use the 

following syntax: 

thisform.oleScriptingControl.Object.AddObject( ; 

"frmFoxProForm",Thisform) 

One item you’ll quickly notice is the inclusion of the 

Object keyword. VFP provides this property to deal with 

ActiveX controls that share similar properties and 

methods with VFP objects. If you attempt to call the 

AddObject method without the Object keyword, VFP will 

address the FoxPro version of the AddObject method and 

not the AddObject method of the scripting control. 

Upon adding a reference to your VFP object, you can 

begin addressing the object in your VBScript using the 

first parameter of the AddObject method. The following 

code demonstrates changing properties on a VFP form 

Figure 1. This form demonstrates the capabilities of the Microsoft 

scripting control. 

using VBScript: 

Function SetFormProperties() 

If IsObject(frmFoxProForm) Then 

frmFoxProForm.Caption = "Hello World" 

frmFoxProForm.BackColor = 100000 

End If 

End Function 

This example demonstrates setting properties on a 

VFP object. You can also call VFP methods. The following 

code shows how to call the click event of a button on the 

scripting form: 

Function CallFormMethod() 

If IsObject(frmFoxProForm) Then 

frmFoxProForm.BackColor = 400000 

frmFoxProForm.cmdClickTest.Click() 

End If 

End Function 

Scripting “gotchas” 

When developing applications using the Microsoft 

scripting control, there are some “gotchas” you need to 

take into account. The first deals with adding VFP objects 

to the scripting control using the AddObject method. It’s 

important to make sure the scripting control releases your 

objects when it’s done with them. You can release your 

VFP controls by calling the scripting control’s Reset 

method. If you don’t use the Reset method, VFP might 

get a visit from Dr. Watson when you release the form 

with the scripting control on it. The best place to put the 

Reset call is in the QueryUnload event of the scripting 

control’s form. 

While I’m talking about Dr. Watson, there’s another 

item to take into account. If you use ActiveX controls in 

your applications, you need to turn FoxPro’s ActiveX 

Dual Interface option off. You do this by putting the 

following call in either your main program or in the Load 

method of your form: 

*-- Turn ActiveX Dual Interface Option Off 

SYS(2333,0) 

If you don’t do this, FoxPro won’t release your 

forms correctly. 

Finally, for good measure, it’s always a good idea to 

call the scripting control’s Reset method after executing 

code. The reason for this is that the control has a tendency 

to become unstable if you call the AddCode method 

repeatedly. 

Conclusion 

Now that you have a basic understanding of using the 

scripting controls, you might say, “So what good does this 

do me?” Here are some uses I’ve already found handy: 

• Add your own macro language to your applications. 

(Hint: Use a memo field for storing code.) 

• Adopt existing Visual Basic or JavaScript code, like 



functions stored in Active Server Pages. 

• Even use an alternate language for building your 

FoxPro applications. 

You’re only limited by your creativity when it comes 

to adding scripting to your applications. 

Finally, I’d like to thank two people for assisting me 

with this article: Ken Levy, for inspiring it in the first 

place, and John Petersen, for making sure my article 

Transactions: Tahoe and MTS . . . 


that resources get released: 




*-- Open database and view. 

OPEN DATABASE Test 

USE Account 

*-- Check the balance. 

nBalance = account.balance 

*-- Complete transaction. 


CLOSE DATABASES ALL 

RETURN nBalance 

“Gotchas” galore 

Those of you who attend the 1998 Visual FoxPro DevCon 

might notice that my beard is a little grayer this year than 

last. Working with new features of beta software when 

there’s nobody to go to with questions sometimes seems 

to take many years off your life. Furthermore, in a 

distributed environment such as I’ve described, it can be 

tough to know which product’s documentation to refer to 

when you get an error. I hope you’ll benefit from my own 

accelerated aging process. 

MTS components can have no user interface. 

They can’t use commands like WAIT WINDOW or 

MESSAGEBOX(). Nor can ODBC connections open 

ODBC login screens. When you create connections for 

remote views, be certain to use DBSETPROP() to set the 

connection’s DispLogin property to 3 to ensure that the 

user is never prompted. 

MTS components are always in-process servers. In the 

past, there was no difference in VFP between multi-use inprocess 

servers and single-use in-process servers. Tahoe 

OLEPUBLIC classes that will be used in MTS must be set 

for multi-use instancing. 

Debugging servers running in MTS can be a little 

tricky to debug. The process goes something like this: 

Create DLL, create MTS package, run code, crash. So then 

would be useful for other VFP developers. ▲ 

06PADDOC.ZIP at www.pinpub.com/foxtalk 

Rod Paddock is president of Dash Point Software, Inc., which is 

based in Seattle, and specializes in developing applications using Visual 

Interdev, VFP, VB, and SQL Server. DPSI was a finalist in the 1998 Visual 

FoxPro Excellence Awards. Rod is currently working with John Petersen 

on his new book, Visual FoxPro 6 Enterprise Development 

(Prima Publishing). www.dashpoint.com, rpaddock@dashpoint.com. 

you make a change in your code and attempt to rebuild 

the DLL. But the DLL is in use and can’t be overwritten. 

The problem is that MTS keeps components in memory 

for faster reuse. In the Transaction Server Explorer, you 

can select the correct computer, right-click, and choose the 

Shutdown Server Processes option. If you try to build the 

DLL again and get the same error, you might want to 

resort to using the Task Manager to end the processes 

instead. Open the Task Manager and look for “MTX.EXE” 

on the Processes page. You might see it in the list more 

than once. Select it and click the End Process button. 

Don’t try this except on development machines. 

Don’t forget that your in-process servers aren’t 

running in your application’s process, they’re running in 

an MTS process. Any environment settings you’ve made 

in your application don’t apply in the MTS process. I aged 

seven years just because of a file-in-use error due to my 

failure to remember to SET EXCLUSIVE OFF. 

More to come 

No, I’m not planning another article in this series, but be 

sure to look for Jim Falino’s upcoming how-to article that 

discusses the specific implementation tricks and tips. 

I’m very excited about the possibilities presented by 

Tahoe and MTS. Although there’s much room for 

improvement, the combination offers many advantages 

to client/server application developers today. And 

when SQL Server 7 is available later this year with its 

embeddable SQL Desktop, those advantages will be 

available for all applications. There will be nothing to stop 

me from delivering the most powerful, robust database 

applications to all my clients, whether they have a 

hundred workstations or one laptop. ▲ 

Gary DeWitt is software magician at Sunpro, Inc., the leader in fire service 

software. He lives on the California shore of Lake Tahoe and is convinced 

the next version of Microsoft Visual FoxPro, code-named Tahoe, was 

named with him in mind. While Visual FoxPro is his favorite development 

tool, he also programs in C++, Java, and Visual Basic. Gary is a Microsoft 

Certified Professional and Microsoft Most Valuable Professional. 

gdewitt@sierra.net. 


17

Synchronized Swimming 

Paul Maskens and Andy Kramek 

This month, Paul and Andy show how to make multiple forms 

with private Datasessions navigate to the same record. 

Andy: Here’s a nice little problem, Paul. I’ve got a form 

(running in a private DataSession) that’s used to display 

saved Visual FoxPro forum messages, and obviously I 

want to be able to search the underlying table to find a 

particular message. This search might be by Subject, by 

Author Name, by Thread number, and so on. I just don’t 

know which will be needed at any particular moment. I 

could simply use a popup form with, say, a grid on it, 

select the message I want, pass its record number back to 

the main form, and then do a LOCATE and REFRESH 

there. However, it seemed to me that linking the two 

forms in some way would be a cleaner (and, more 

importantly, more generic) approach. 

My first thought was to have the forms share a 

common DataSession—after all, that’s pretty easy to do 

when the child form is modal. You just set its DataSession 

to 1 (Default), and it will inherit its DataSession from the 

parent form. 

Paul: Yeah, but that’s undocumented behavior, isn’t it? 

Can we really rely on it? And doesn’t it also cause 

some problems with DataSession names? Despite the 

DataSession name getting lost, this technique worked in 

VFP 3. But I’ll have to retest it in 5.0 and 6.0 if I ever 

recompile that application. 

Andy: Well, it’s true that VFP does seem to lose track of 

the DataSession name upon returning from a child form 

set up in this way—it just shows “Unknown” as the 

DataSession name. But it doesn’t seem to affect anything. 

As for relying on behavior that’s undocumented—you 

have a point. Remember—back in 3.0—the “Empty” base 

class that’s used when you do a “SCATTER NAME”? That 

was undocumented and exposed in VFP 3.0, but it 

disappeared without warning in 3.0b! 

On second thought, better to make the child form 

switch itself to the parent form’s DataSession. We can do 

that by passing the parent form’s DataSessionID property 

to the child form like this: 

DO FORM frmChild WITH ThisForm.DataSessionID 

In the receiving form, just set the DataSessionID property 

in the Init() method, like this: 

LPARAMETERS tnDSID 

ThisForm.DataSessionID = tnDSID 

The Kit Box FoxTalk 

Paul: Oh, great! But what happened to my bound controls 

when I did that? After all, they’ve already been initialized 

in the child form’s DataSession—now I’m switching it! Is 

that what made all my controls lose their controlsources? 

Andy: Hmm. A good point. Any bound controls will 

irrevocably lose their binding. I suppose we could reset 

them all in the Init() (or a custom method called by 

the Init())? 

Paul: Yes, that would work. However, I prefer a method 

called by the Init, although this would be a bit of a pain if 

you had a pageframe with 40 controls on each of three 

pages! I suppose you could go through the .controls[] 

collection and reset the controlsource properties, but there 

has to be a better way than recursion into every container 

you have on your form. 

Andy: Okay, wise guy—what do you suggest, then? 

Paul: Pass the Primary Key of the current record between 

the forms! However, instead of diving in and creating my 

own methods to send and receive the Primary Key, I 

cheated. I used Drag and Drop to link two forms! 

On the “sending” form, I had a command 

button that assigned the table’s Primary Key (well, 

ALLTRIM(STR(ID), actually) to its caption as I moved the 

mouse over it. Then I set the DragMode of the button to 

Automatic in the Properties window. 

The “receiving” form looked at the caption of the 

object it received in its DragDrop method and then did a 

SEEK() on VAL() of that object’s caption. 

So I had two forms that were sort of loosely coupled. 

The receiving form could navigate separately because it 

used a private DataSession. The sending form would 

always navigate separately, again with a private 

DataSession. Just drag the button from the sending 

form to the receiving form—voila! Record pointers 

synchronized . . . 

Andy: That’s pretty neat! It does depend on user 

intervention, though, doesn’t it? I mean, what happens if 

they close the child form without dragging the button to 

it? Not much, I suppose? 

Paul: Absolutely right! You see, I intended this mechansim 

to be a way of linking an overview to a detail form when 

required, not permanently. You got me thinking, though. 



It’s only a moment’s work to add a “LINK” check box, 

and another moment to use Refresh() to set the cmdLink 

caption instead of waiting for the mouse. Refresh() is 

called after record navigation to update the contents of all 

the controls. Next, add a test in the sending form’s 

Refresh() like so: 

IF chkLink.value = .t. 

Form2.DragDrop(THISFORM.cmdLink). 

ENDIF 

Andy: Whoa! Slow down a bit there, you’ve lost me. 

Explain how these two forms link themselves again— 

how does one form “know” about the other one? 

Paul: Okay, I know the name of Form2, right? So I can 

loop through the _SCREEN.Forms[] collection looking for 

the Name. I could have used the Caption property, or 

Comment, or Tag—Name seems easiest. 

When I find it, I can fake a DragDrop event dropping 

on Form2 by calling the DragDrop() method with 

parameters that look like a real DragDrop has happened. 

You know that events happen. What VFP does when 

an event happens is to run the code in the method with 

the same name to handle any special actions when the 

event happens. So if I call that method directly, the 

program can’t tell the difference. 

I set the command button’s caption, then call this: 

_SCREEN.Forms[i].DragDrop(THISFORM.cmdDrag,0,0) 

to fool VFP into running my navigation code in the form. 

LPARAMETERS oSource, nXCoord, nYCoord 

SELECT (THISFORM.MainTable) 

lnOldRec = RECNO() 

SEEK VAL(oSource.caption) 

ENDIF 

I made it a little more complex, because my program 

fakes DragDrop with coordinates of 0,0, and I assume 

anything other than that is a real drop. So the focus should 

be set to THISFORM—Form2. 

Without any extra custom methods and with only one 

object (perhaps an invisible Label), you could link two 

forms together. Yes, before you say it, I think properly 

named methods are a good idea. I’m overloading 

DragDrop to make it do something it isn’t meant to do. 

However, a better way is to have a set of interacting 

objects in a Mediator-Colleague pattern. 

Andy: Huh? What does that mean? 

Paul: The Mediator receives messages and sends them to 

every Colleague it knows about, except the sender. The 

Colleague registers with a Mediator and processes any 

message it receives. 

Andy: Ah, I see. So in our example, the parent form would 

originate a message and send it to the Mediator object, 

which in turn would simply pass it on to the objects it 

knows about. The child form is then responsible for 

registering with the Mediator so that it can receive 

(and presumably send) messages by that route. That’s 

pretty cool! 

Paul: Right (or possibly wrong ). In your Application 

object, you’d need to have a Register(toColleague) 

method where other objects sign up to receive messages. 

Any object that wants to receive messages has to have a 

HandleMessage() method. 

Andy: Hang on there, fellah—this all sounds a bit specific. 

I don’t use an Application object all the time. Wouldn’t 

it be better if you made your Mediator a class in its 

own right? 

Paul: I think so. This would mean all the pointers to the 

registered objects and the code that passes messages to 

them would be encapsulated in an object. That’s proper 

OOP. For now, though, I’d like to keep it simple and 

assume your Application object exists and is called 

goApp. 

Andy: Okay, I’ll buy that for now. So how does it all work 

in practice? 

Paul: Easy. In the Init(), your form class has a call to 

goApp.Register(THIS). The Application object’s 

Register(toColleague) method stores the object pointer 

in a 2-D array, along with SYS(1272,toColleague). That 

SYS() function gets the containership hierarchy and 

the name of the object—which will be needed later! 

So, to recap: goApp.aColleague[i,1] is the object, 

goApp.aColleague[i,2] is its name. 

Your Application object should also have a 

Mediate(tcMessage, toSender) method. This loops 

through the stored object array (why use i? It’s a sort 

of tradition ) and checks—using the 

SYS(1272,toSender)—to see whether the entry in 

.aColleague[i,2] matches. If it does, ignore it—you 

generally don’t want to send the message back 

to the sender. Otherwise, call the 

.aColleague[i,1].HandleMessage(tcMessage). 

That’s it! 

Andy: Aha! I get it now. That SYS(1272) call is working 

around the fact that we can’t compare objects with each 

other. So my Form class has to have an extra method 

HandleMessage() and a call (presumably conditional) in 

its Init() to the mediator Register(), like this: 

PROCEDURE INIT 

IF TYPE( 'goApp') = "O" AND ! ISNULL( goApp ) 

goApp.Register( THIS ) 

ENDIF 

But what goes into the HandleMessage() method? 

Paul: That depends on what messages you want the object 

to react to. Of course, you need to define some 

standards—like perhaps “SEEK:“. 


19

Then you can just use a CASE statement in the 

HandleMessage() method to define which messages to 

recognize: 

DO CASE 

CASE tcMessage = "SEEK:" 

*** React to this message 

lnPK = VAL( SUBSTR( tcMessage, 6 )) 

SEEK lnPK 

OTHERWISE 

*** Do nothing - ignore the message 

ENDCASE 

Andy: Just one thought. Haven’t we now got an external 

reference to an object in the Mediator? Doesn’t this mean 

that we can no longer release the object? 

Paul: Correct! So we also need an UnRegister() method 

that’s called from each Form’s Unload() method. Like 

Register(), goApp.UnRegister(THIS) would suffice. 

All it needs is to loop through .aColleague[i,1] again, 

testing SYS(1272, toSender) as before, but this time, on 

finding a match, just set .aColleague[I,2] to .NULL. so that 

the object reference is discarded. 

Oh, and about your desire for reusable classes? Here’s 

one I prepared earlier, in the best Blue Peter tradition . . . 

Class cusMediator is the Mediator half of the pattern. 

This can either be added to a form at design time, in 

which case it should be named “oMediator”, or it can be 

created as an uncontained object, in which case it should 

be referred to by a global variable goMediator. 

************************************************** 

*-- Class: cusMediator 

* 

#DEFINE _CR CHR(10) 

* 

DEFINE CLASS cusMediator AS custom 

*-- Number of registered colleague controls 

nColleagues = 0 

Name = "cusMediator" 

*-- Array of colleague control Hierarchy, oRef. 

DIMENSION acolleagues[1,2] 

*-- Called by colleague to register itself with 

*-- the Mediator 

PROCEDURE register 

LPARAMETERS toColleague 

WITH THIS 

.nColleagues = .nColleagues +1 

DIMENSION .aColleagues[ .nColleagues, 2] 

.aColleagues[ .nColleagues, 1] ; 

= SYS( 1272, toColleague ) 

.aColleagues[ .nColleagues, 2] = toColleague 

ENDWITH 

IF TYPE("glDebug") != "U" 

IF "Visual FoxPro 05" $ VERS() 

DEBUGOUT THIS.Name +" register()" +_CR ; 

+SYS( 1272, toColleague ) +_CR ; 

ELSE 

WAIT WINDOW THIS.Name +" register()" +_CR ; 


TIMEOUT 2 

ENDIF 

ENDIF 

ENDPROC 

*-- Removes all object references to colleagues, 

*-- call before the Destroy() to prevent GPFs 

PROCEDURE cleanup 

LOCAL lnCount 

WITH THIS 

FOR lnCount = 1 TO .nColleagues 

.aColleagues[ lnCount, 1] = "" 

.aColleagues[ lnCount, 2] = .NULL. 

NEXT 

.nColleagues = 0 

ENDWITH 

ENDPROC 

*-- Receives Source object and message to 

*-- mediate (String) 

PROCEDURE mediate 

LPARAMETERS toColleague, tcMessage 



DEBUGOUT THIS.Name +" mediate()" +_CR ; 

+tcMessage +_CR ; 

+SYS( 1272, toColleague ) 

ELSE 

WAIT WINDOW THIS.Name +" mediate()" +_CR ; 


+SYS( 1272, toColleague ); 

TIMEOUT 2 

ENDIF 

ENDIF 

RETURN THIS.SendMessage( toColleague, tcMessage ) 

ENDPROC 

*-- Sends the message received by Mediate() to all 

*-- the colleagues registered EXCEPT the one 

*-- that sent it 

PROCEDURE sendmessage 

LPARAMETERS toColleague, tcMessage 

LOCAL lcColleague, lnColleague, llStatus 

WITH THIS 

lcColleague = SYS( 1272, toColleague ) 

llStatus = .T. 

FOR lnColleague = 1 to .nColleagues 



DEBUGOUT THIS.Name ; 

+"sendmessage("+allt(str(lnColleague))+")"; 

+_CR ; 

+.aColleagues[ lnColleague, 1] 

ELSE 

WAIT WINDOW THIS.Name ; 

+"sendmessage("+allt(str(lnColleague))+")"; 

+_CR ; 

+.aColleagues[ lnColleague, 1] ; 

TIMEOUT 2 

ENDIF 

ENDIF 

IF NOT( .aColleagues[ lnColleague, 1] ; 

== lcColleague ) 

IF .aColleagues[lnColleague,2] ; 

.Receive(tcMessage) 

* 

* Do nothing, assumes all colleagues receive OK 

* 

ELSE 

* 

* Note colleague failed to handle message 

* 

llStatus = .F. 

ENDIF 



DEBUGOUT THIS.Name ; 

+" sendmessage()" +_CR ; 

+.aColleagues[ lnColleague, 1] +_CR ; 

+IIF(llStatus,"OK","Fail") 

ELSE 

WAIT WINDOW ; 

THIS.Name +" sendmessage()" +_CR ; 

+.aColleagues[ lnColleague, 1] +_CR ; 

+IIF(llStatus,"OK","Fail") ; 

TIMEOUT 2 

ENDIF 

ENDIF 

NEXT 

ENDWITH 



*

* If any colleague failed to handle the message, 

* the status will be .F. and not .T. as set 

* earlier 

* 

RETURN llStatus 

ENDPROC 

PROCEDURE unregister 

LPARAMETERS toColleague 

LOCAL lnColleague, llRetVal 

WITH THIS 

lnColleague = ASCAN( .aColleagues, ; 

SYS( 1272, toColleague )) 

IF lnColleague != 0 

lnColleague = ASUBSCRIPT( .aColleagues, ; 

lnColleague, 1 ) 

llRetVal = .t. 

.aColleagues[ lnColleague, 1] = "" 

.aColleagues[ lnColleague, 2] = .NULL. 

= ADEL( .aColleagues, lnColleague ) 

DIMENSION .aColleagues[ .nColleagues, 2 ] 

ELSE 

llRetVal = .f. 

ENDIF 

ENDWITH 



DEBUGOUT THIS.Name +" UnRegister()" +_CR ; 


ELSE 

WAIT WINDOW THIS.Name +" UnRegister()" +_CR ; 


TIMEOUT 2 

ENDIF 

ENDIF 

RETURN llRetVal 

ENDPROC 

ENDDEFINE 

* 

*-- EndDefine: cusMediator 

************************************************** 

Class cusColleague is the Colleague half of the 

pattern. This class can be added to any container, in which 

case the DoAction() method will probably do things to 

THIS.parent—I usually just call a method. I expect that 

the DoAction() method will be overridden in any instance 

or subclass. 

You could make it collaborate with any object, with a 

little modification—like passing THIS to the Init(toClient) 

method and storing that in a property of the Colleague for 

use in the DoAction() method. 

************************************************** 

*-- Class: cusColleague 

* 

#DEFINE _CR CHR(10) 

* 

DEFINE CLASS cusColleague AS Custom 

Name = "cusColleague" 

*-- Message is sent here by mediator, this passes 

*-- it on to DoAction() and returns the result. 

PROCEDURE Receive 

LPARAMETERS tcMessage 



DEBUGOUT SYS(1272, THIS) +" receive()" +_CR ; 

+ tcMessage 

ELSE 

WAIT WINDOW ; 

SYS(1272, THIS) +" receive()" +_CR ; 

+tcMessage ; 

TIMEOUT 2 

ENDIF 

ENDIF 

RETURN THIS.DoAction( tcMessage ) 

ENDPROC 

*-- Performs anything necessary to handle the 

*-- incoming message. Returns success/fail. 

PROCEDURE DoAction 


* 

* This will of course be overridden in an instance 

* of this class! 

* 


DEBUGOUT SYS(1272, THIS) +CHR(13) ; 

+"DoAction( "+ tcMessage +" )" 

ELSE 

WAIT WINDOW SYS(1272, THIS) +CHR(13) ; 

+"DoAction( "+ tcMessage +" )" ; 

TIMEOUT 2 

ENDIF 

RETURN 

ENDPROC 

*-- Given a message (String) it sends it off to 

*-- the mediator referenced through 

*-- THISFORM.oMediator.Mediate() 

PROCEDURE send 


* 

* Send message via form mediator and return. 

* 

IF TYPE("THISFORM.oMediator") != "U" 



DEBUGOUT SYS(1272, THIS) +" send()" +_CR ; 


+"Form Mediator" 

ELSE 

WAIT WINDOW ; 

SYS(1272, THIS) +" send()" +_CR ; 


+"Form Mediator"; 

TIMEOUT 2 

ENDIF 

ENDIF 

RETURN THISFORM.oMediator.Mediate( ; 

THIS, tcMessage ) 

ENDIF 

* Unless there isn't one! 

* Send message via global mediator and return. 

* 

IF TYPE("goMediator") != "U" 





+"Global Mediator" 

ELSE 

WAIT WINDOW THIS.Name +" send()" +_CR ; 


+"Global Mediator"; 

TIMEOUT 2 

ENDIF 

ENDIF 

RETURN goMediator.Mediate( THIS, tcMessage ) 

ENDIF 

* 

* No mediators on standard interfaces, fail. 

* 





+"NO Mediator - FAILED" 

ELSE 

WAIT WINDOW THIS.Name +" send()" +_CR ; 


+"NO Mediator - FAILED"; 

TIMEOUT 2 

ENDIF 


21

ENDIF 

RETURN .F. 

ENDPROC 

PROCEDURE Init 

* 

* Register with form mediator and return. 

* 


RETURN THISFORM.oMediator.Register( THIS, .F. ) 

ENDIF 


* Register with global mediator and return. 

* 


RETURN goMediator.Register( THIS, .F. ) 

ENDIF 

* 


* In failing this will prevent FORM 

* instantiation under VFP 3, but this object 

* will merely not exist under VFP 5 

* 

RETURN .F. 

ENDPROC 

PROCEDURE Destroy 

* 

* Remove from form mediator and return. 

* 


RETURN THISFORM.oMediator.UnRegister( THIS ) 

ENDIF 


* Remove from global mediator and return. 

* 


RETURN goMediator.UnRegister( THIS ) 

ENDIF 

* 


* 

Editorial: Enter Sandman . . . 


so let’s do it. I mean, wouldn’t it be cooooool?” Who gives 

a rip if it should be done? They’ve got the business in a 

perpetual death grip of one-upmanship. Their processor 

runs at 410 MHz. Let’s make ours run at 450—and we’ll 

price it lower! 

I’m not saying I want to go back to dBASE II. We’ve 

had some wonderful advances that are a joy to work 

with. Visual FoxPro is still a thrill a minute (including the 

thrills you get when Dr. Watson comes to visit ). 

And the rumor is that Office will be using a single 

code-base worldwide next year. That’ll be a nice change, 

don’t you think? 

It’s the same in the music industry. If you’re going to 

follow bands these days, you have to be nimble. This 

month’s hot news is next month’s history. I’m reminded 

of the scene in the movie “Clueless,” where several 

teenage girls are checking out a jacket in the mall. One 

derides the jacket as “so five minutes ago.” The other 

decides not to buy. Fashionable today, boring tomorrow. 

RETURN .F. 

ENDPROC 

ENDDEFINE 

* 

*-- EndDefine: cusColleague 

************************************************** 

Paul: I’ve left it in my debugging code, which I control 

using the existence of the global variable glDebug. This is 

a hangover from VFP 3, where we had no debug output 

window, yet I wanted to control whether or not my debug 

output appeared. It’s not defined because I’m not usually 

debugging this code. If you want to see those messages, 

simply type “glDebug = .t.” and press Enter in the 

Command window. 

You’ll notice that I’ve adopted a belt-and-braces 

approach in the Colleague class. I’ve checked for both a 

global mediator object (goMediator) and a mediator object 

added to the current form (THISFORM.oMediator) 

because I wasn’t sure how it might be used. I haven’t 

added a third test for goApp.oMediator because I believe 

in using separate public variables for various managers. 

Practical OOP here, Andy. 

Andy: I’m speechless with admiration! ▲ 

Paul Maskens is a VFP product specialist who works for the Visual 

Development Studio of Chelmsford, based in Oxford, England. 

pmaskens@compuserve.com. 

Andy Kramek is a long-time FoxPro developer, independent 

contractor, and occasional author based in Birmingham, England. 

andykr@solihull.bytenet.co.uk. 

So you’re going to have to be just as nimble to follow 

the software trends. Yesterday’s big news is today’s 

yawn. Don’t you feel a little cheated if you’ve made a big 

investment in last year’s alphabet soup of database access 

acronyms, and then did it again this year, only to find out 

it doesn’t all really work yet, and you’re going to have to 

do the learning curve again next year? 

Where I’m heading with this, though, is that the next 

couple of years are going to be decision time for a lot of 

us. People in my user group complain because we want to 

send out meeting notices via e-mail. “Sure, I have e-mail. 

But I only check it about once a month.” C’mon! As a 

friend of mine said (and as I’ve echoed in this column 

before), “If you’re not willing to make a professional 

investment in your career here, then run, don’t walk, to 

the exit of this industry.” 

I’m tired. Time to go home. I’m going to pull a cold 

one from the fridge, turn off all the lights, and listen to 

one of the all-time greats in heavy metal. Classics never 

go out of style, and neither will “Enter Sandman.” I’ll 

have more energy tomorrow. I’ll need it, to stay up with 

these young whippersnappers . . . ▲ 



Traversing Transactions . . . 




ELSE 



ENDIF 

ENDIF 

ENDIF 

IF llRollBack 

ROLLBACK 

ELSE 

ENDTRANSACTION 

ENDIF 

The preceding code is pseudo-code, so don’t take it 

literally. Here I used a series of nested IF statements to 

control the actions. I could have put all of the aliases in an 

array and used a FOR/ENDFOR loop to go through them, 

exiting the loop when they were all done or when any one 

of them failed. 

What can go wrong? 

In the preceding pseudo-code, assume that the transaction 

failed and that you issued the ROLLBACK. What, exactly, 

do you roll back to? Are the buffers returned to their 

pre-edit state, or are the buffers still dirty with the 

user’s edits? 

The answer is that the buffers are restored to the 

dirty state that they were in prior to the BEGIN 

TRANSACTION. This means that you still have to deal 

with the user’s edits. You have the control here—you can 

put the user back into the form and let him or her decide 

what to do, or you can TableRevert all the aliases and 

discard the user’s work. This is all up to you in the code 

that you write. 

What happens if the computer shuts off during the 

transaction? Obviously, VFP has no record of the 

transaction when the system is restarted. So did some of 

the tables get updated or not? None of the tables got 

updated, none of the buffers are dirty, and the result is 

just as if a ROLLBACK had been executed. 

Another situation that’s occurred and caused a 

Tame Your ActiveX Controls . . . 


acts as the placeholder for the TreeView control. The 

cNewObjectName properties for oTreeViewLoader 

and oImageListLoader specify the names of the controls 

to create (oTree and oImageList, respectively). 

oTreeViewLoader also has the name of the placeholder 

object (shpTreeView) in its cObjectName property and 

the name of the TreeView subclass we want to use 

(MyTreeView) and its location (ACLASSES.PRG) in the 

cClass and cLibrary properties. The Init method of the 

form sets some properties for the ActiveX controls, 

loading images in the case of the ImageList and nodes in 

the case of the TreeView. 

lot of problems is when the developer puts together a 

form and puts a BEGIN TRANSACTION in the Init and 

issues either an ENDTRANSACTION or a ROLLBACK 

in the destroy, depending on which button the user 

chose to exit the form. What problems could this cause? 

The first is that no other user can do anything with any 

of the tables involved in this form until the current user 

exits the form and releases the locks. I’ve seen this 

situation used as an argument against transactions—well, 

come on now, anything that’s used incorrectly can cause 

problems. Transactions used correctly will limit the 

time between the beginning and ending to the smallest 

period possible. The Init to Destroy of a form is 

certainly not the smallest time period possible—it’s 

a time period that’s not even under the control of 

the developer. 

It’s been said that VFP’s transactions aren’t as 

“robust” as the transaction handling of client/server 

database servers. I say, so what? Is the fact that a semi 

tractor has brakes that are more “robust” than the brakes 

on my car a reason to not use my car’s brakes? No, it’s 

not. VFP’s transactions are helpful, and they serve a 

purpose. They should be used, even when the data is 

stored in a client/server database. 

Conclusion 

Transactions in VFP are a very valuable feature of the 

product. They allow you to group a number of update 

operations into one “all or none” operation. In today’s 

world, you seldom build forms that only manage a single 

table—the multi-table form has become the norm. 

Managing these multi-table updates becomes a very 

important aspect of your work, and transactions are 

invaluable in doing this. ▲ 

Jim Booth is a Visual FoxPro developer and trainer. He has spoken 

at FoxPro conferences in North America and Europe. Jim has been 

a recipient of the Microsoft Most Valuable Professional Award 

every year since it was first presented in 1993. 203-758-6942, 

72130.2570@compuserve.com. 

local loPicture 

* Load the ImageList images. 

with This.oImageList 

loPicture = loadpicture('AUDIO.ICO') 

.ListImages.Add(, 'Audio', loPicture) 

loPicture = loadpicture('DESKTOP.ICO') 

.ListImages.Add(, 'Desktop', loPicture) 

endwith 

* Set some TreeView properties. 

with This.oTree 

.ImageList = This.oImageList.Object 

.Style = 7 

.LineStyle = 1 

.LabelEdit = 1 

.HideSelection = .F. 

.Indentation = 25 

* Load the TreeView with sample nodes. 

.Nodes.Add(, 1, 'Top1', 'First Top Node', 'Audio') 


23

.Nodes.Add(, 1, 'Top2', 'Second Top Node', 'Audio') 

.Nodes.Add('Top1', 4, 'Child1', 'First Child Node', ; 

'Desktop') 

.Nodes.Add('Top1', 4, 'Child2', 'Second Child Node', ; 

'Desktop') 

.Nodes.Add('Top2', 4, 'Child3', 'Third Child Node', ; 

'Desktop') 

.Nodes.Add('Top2', 4, 'Child4', 'Fourth Child Node', ; 

'Desktop') 

endwith 

Summary 

ActiveX controls are both wonderful and terrible. They’re 

wonderful because they can give your applications the 

professional, polished look users expect from modern 

32-bit applications (the TreeView control that comes with 

VFP and the ctListBar control from dbi technologies inc. 

are good examples), or they can provide advanced 

capabilities that would either be impossible or very 

time-consuming to create in VFP code (the DynamiCube 

control I discussed in my March 1998 column is an 

Downloads 

June Subscriber Downloads 

• 06DHENSC.ZIP—Source code described in Doug Hennig’s 

article. SFCTRLS.VCX and SFACTIVEX.VCX are class libraries 

used to support TREEVIEW.SCX, a sample form that shows 

how to add ActiveX controls at runtime. SFREGISTRY.VCX 

provides access to the Windows Registry. 

• 06PADDOC.ZIP—Source code for two items discussed in Rod 

Paddock’s article. CODEBLCK.PRG is Randy Pearson’s Code 

Block command window replacement. SCRIPTING.SCX is a 

sample form that demonstrates how to use the scripting 

control in VFP. 

Extended Articles 

• 06COOL.HTM—Extended Article. How do you keep current 

Help is a Mouse-Click Away: Introducing Developer Solutions–Online at www.pinpub.com 

When a programming crisis or dilemma comes up, you need 

dependable solutions fast. Technical support calls are eating your 

time and costing hundreds of dollars—even when you don’t get 

solid answers from them. In response to your needs, we’re proud 

to announce a new online search mechanism to help you find the 

information you need when you need it. 

Check out the continually updated Pinnacle Publishing 

index of expert-written articles at www.pinpub.com (tell your 

colleagues!). You’ll be able to access each monthly issue of 

FoxTalk, SQL Server Professional, Smart Access, and Visual Basic 

Developer from 1996 through the present. You can view the entire 

online Table of Contents of a newsletter or enter a search term to 

pinpoint all of the available related articles. The search is free, tips 

are free, and articles (including any corresponding Subscriber 

Download files) can be downloaded for a nominal fee. 

Here’s how it works: Go to www.pinpub.com and click on 

Developer Solutions—Online. Enter the search term of your 

Portions of the FoxTalk Web site are available only to paid 

subscribers of FoxTalk. Subscribers have access to additional 

resources to give you an edge in FoxPro development. 

example of that). They’re terrible because when “OLE 

class not registered” or other OLE errors occur, you can’t 

just roll up your sleeves and use the VFP Debugger to 

track down the problems. SFActiveX has been a life saver 

for me; it handles the main problem I have with ActiveX 

controls. I’m sure you’ll find it as useful as I have. ▲ 

06DHENSC.ZIP at www.pinpub.com/foxtalk 

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 Database Toolkit and Stonefield 

Query. 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 the 1997 and 1998 Microsoft FoxPro Developers Conferences 

(DevCon), as well as user groups and regional conferences all over North 

America. He is a Microsoft Most Valuable Professional (MVP). 

75156.2326@compuserve.com, dhennig@stonefield.com. 

with everything that’s happening to the wide array of tools 

you’re using? Woody’s Office Watch is a free weekly e-mail 

that covers everything that’s happening with Microsoft 

Office. Also covered: Directory Toolkit, a shareware tool that 

pulls together a number of features that you’d like to see in 

Windows Explorer. 

• 06COOL.ZIP—Contains SETUPDT.EXE, the installation file for 

Directory Toolkit, a shareware utility described in this 

month’s Cool Tool column. 

• 06PETER.HTM—Extended Article. This month, John Petersen 

addresses the topic of where to place your Automation 

code: in the VFP application, in the Office application, or, in 

the case of Tahoe, in a VFP COM object. 

choice to access any of the material we’ve published on 

this topic. Alternatively, you can click on “Contents” on the upperleft 

side of the screen to list any of the published material by 

issue date. 

Possible uses: 

• Use the search function to find an article you can’t locate 

in your back issues. 

• Find all of our published articles on a given topic. 

• Use the pay-per-view option to access articles published 

before your subscription started by following the online 

sign-on instructions. (You’ll be able to access the download 

file as well.) 

• Browse the “Contents” portion for summaries of articles and 

free tips that have been published in FoxTalk and our other 

publications. 

Coming soon: Online subscription options! 

User ser name 

Passw assw asswor or ord 

kerosene 

lantern

Tame Your ActiveX Controls Doug Hennig - dFPUG-Portal

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?