Un-Mapping Mapped Network Drives Andrew Coates - dFPUG-Portal

FoxTalk 

Solutions for Microsoft® FoxPro® and Visual FoxPro® Developers 

Un-Mapping Mapped 

Network Drives 

Andrew Coates 

6.0 

One commonly stored piece of information is the location of a file or folder. If that 

file or folder is on the network, however, different users might refer to the location 

through different drive mappings. In this article Andrew shows how to decode the 

mapped location using the Windows API so that any user can view or retrieve the 

file or folder. 

I 

learned something this week that I guess I should have known. The 

Win32API isn’t consistent across operating systems. There are functions 

that work fine under Windows NT but fail miserably when called under 

Win95. I found one when working on the subject matter for this article. 

Mapping network drives is a common way of simplifying network storage 

systems from a user’s point of view. Unfortunately for the cause of universal 

access, however, different users map network shares to different driver letters. 

If your application allows users to store links to files, how can you tell whether 

E:\COMMON DOCUMENTS\BUDGET98.XLS and W:\BUDGET98.XLS refer 

to the same document? Even more importantly, how can a third user who has 

neither E: or W: mapped retrieve the document? 

The answer is UNC. The Universal Naming Convention uses the 

format \\SERVER\SHARENAME\ to refer to the location of a file or folder. 

In the preceding example, the first user might have mapped drive E to 

\\SERVER_PDC\PUB, and the second might have mapped drive W to 

\\SERVER_PDC\COMMONDOC. 

Any Visual FoxPro function that accepts a path as a parameter will handle 

UNC paths. However, returning a UNC path from the getfile() and getdir() 

functions is a completely different matter. These functions are central to 

allowing your users to specify the location of files and folders. The getfile() 

function will return a UNC path, but only if the user navigates to the file 

Continues on page 3 

December 1998 

Volume 10, Number 12 

1 Un-Mapping Mapped 

Network Drives 

Andrew Coates 

3 Editorial: Bug Fixes Available 

at microsoft.com 

Whil Hentzen 

6 Best Practices: Seeing 

Patterns: The Mediator 

Jefferey A. Donnici 

10 Reusable Tools: Mining 

for Gold in the FFC 

Doug Hennig 

15 ActiveX and Automation 

Review: Integrating ADO 

and Visual Basic into Your 

VFP Applications, Part 2 

John V. Petersen 

19 The Kit Box: Second Star 

on the Right and Straight 

on ’til Morning 

Paul Maskens and Andy Kramek 

23 December 

Subscriber Downloads 

EA Creating a Set of Business 

Rules and the Making of 

a BusinessRule Server 

Stephen Settimi 

EA To Open the Tables 

or Not to Open the Tables— 

That is the Question 

Jim Booth 

EA Follow-up: To PrintScreen 

or Not to PrintScreen 

Art Bergquist 

6.0 

Applies to VFP 

v6.0 (Tahoe) 

Applies to 

VFP v5.0 

Applies to 

VFP v3.0 

Accompanying files available online 

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

Applies specifically to one of these platforms. 

Applies to 

FoxPro v2.x

2 FoxTalk December 1998 

http://www.pinpub.com

Bug Fixes Available 

at microsoft.com 

Whil Hentzen 

IN the olden days of Fox Software, the gang would fix 

bugs and release patch disks. Some of you remember 

the 11 sets of patches for FoxPro 2.0, including two that 

were released, ahem, four days apart. The patches were 

shipped out for free (I think), but you had to know about 

the patches and request them. 

Distribution of bug fixes is a lot easier these days— 

nearly painless—because of the Web: Just go to the site 

and download them. But you still have to know about 

them. And if you don’t “know someone,” how are you 

going to find out? You could visit the Web site of the 

manufacturer of every product you use, but that’s not 

always a great solution. And even if you had the time, 

sometimes it takes a lot of digging. 

Visual Studio SP-1 (”SP” = Service Pack—softie speak 

for bug fixes) is now available for free order and 

download from Microsoft. It addresses specific binary 

compatibility issues with certain runtime files in Visual 

Studio 6.0—none of which I found applicable to VFP—but 

it’s probably still worthwhile getting. 

A more important update—and one that’s fairly 

well hidden—is the new Setup Wizard. If you’ve gotten 

to the point of shipping a VFP 6 application, you’ve 

possibly run into one or more of the half-dozen defects in 

the current Setup Wizard. A couple were pretty ugly, I 

think, but remember that FoxPro 2.5 shipped, and then 

Un-Mapping . . . 

Continued from page 1 

through the Network Neighborhood—something a user 

who’s used to having a network drive mapped is unlikely 

to do. The getdir() function is even worse. There’s no way 

of getting it to return a UNC path to a folder (except in 

one specific instance—see the sidebar “Returning a UNC 

Path from getdir()” for details). Not only do the functions 

not return UNC paths, but VFP doesn’t provide any way 

to convert a mapped path to a UNC path. 

Win32API to the rescue! 

The Windows 32-bit API provides a function that 

accepts a mapped path and returns the UNC path that 

From the Editor FoxTalk 

everyone found out that the Standard version 

didn’t work—period. Turns out everyone was 

testing the Extended version with their brand-new 

386 machines. Similarly, testing the Setup Wizard is 

pretty tough, considering you need a functioning 

app first. 

What’s been fixed? Options for creating a DEP file 

are now saved in WZSETUP.INI. Set Mark To “.” 

doesn’t blow out the distribution disks; neither does 

installing multiple OCX files in the source directory. 

FOXHHELP.EXE is now copied correctly if you check the 

HTML Help Engine check box. And if you have two files 

with the same name but in different directories—like if 

you were shipping a couple of sets of tutorial data—each 

is copied correctly now. 

There’s also an updated VFP 6.0 Component Gallery, 

updates to several FoxPro Foundation Class (FFC) files, 

and an ActiveX control updater that will automatically 

update the Treeview, Listview, and Imagelist controls to 

the latest versions. 

Where do you get these new updates? Pop over 

to msdn.microsoft.com/vfoxpro, and select Samples 

and Downloads, Product Updates, or, if you want the 

direct URL, try http://msdn.microsoft.com/vfoxpro/ 

downloads/updates.asp. Note that your copy must be 

registered before you can get access to the page. ▲ 

corresponds to that mapped path. I searched through 

the API documentation and found a function called 

WNetGetUniversalName() in MPR.DLL in the system 

directory. The function will accept the path to either a file 

or a folder with or without a trailing backslash. 

Unfortunately, this function is only available 

under Windows NT. I found this out the hard way, 

having developed and tested a routine using 

WNetGetUniversalName() on my WinNT development 

box, I proudly installed it on a client’s Win95 machine, 

only to have it not work . Microsoft has a 

Knowledge Base article confirming that it doesn’t work 

under Win95 (there’s no mention in the article of Win98). 

So much for a single, consistent Win32API! 

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

3

What the article does mention, though, is a couple of 

workarounds. The first involves about 30 lines of C code 

that calls another couple of functions in MPR.DLL. The 

second mentions in passing that there’s yet another 

function in MPR.DLL called WNetGetConnection(). 

WNetGetConnection() is not quite as versatile as 

WNetGetUniversalName(). It only accepts a drive letter 

and a colon (for instance, H:) rather than a full path. 

With a little string manipulation, however, it’s pretty 

easy to split up a mapped path, pass the function what it 

wants, and then re-assemble a complete UNC path from 

the pieces. 

To take the drudgery out of calling the Windows API, 

I wrote a wrapper function called GetUNCPath() that I 

include in any project in which I call either getdir() or 

getfile(). You could, of course, write wrappers for getfile() 

and getdir() that called GetUNCPath(). 

For example, if the pub share on the server_pdc 

server were mapped as drive s: 

? GetUNCPath('s:\documents') 

\\server_pdc\pub\documents 

? GetUNCPath('c:\temp') 

c:\temp 

? GetUNCPath('s:\documents\myfile.doc') 

\\server_pdc\pub\documents\myfile.doc 

The wrapper function itself is pretty straightforward. 

The complete function is shown in Listing 1 and is 

available in this month’s Subscriber Downloads at 

www.pinpub.com/foxtalk. It accepts the mapped drive 

path as a compulsory parameter and optionally a length 

for the UNC version of the path. This second parameter is 

most often passed by the function itself in a recursive call 

if the default buffer size guess isn’t large enough (more on 

this later). 

Listing 1. The complete GetUNCPath source code. 

* Program....: GetUNCPath.prg 

* Version....: 1.0 

* Author.....: Andrew Coates 

* Date.......: September 28, 1998 

* Notice.....: Copyright © 1998 Civil Solutions, All 

* Rights Reserved. 

* Compiler...: Visual FoxPro 05.00.00.0415 for Windows 

* Abstract...: Wrapper to the API call that converts a 

* mapped drive path to the UNC path 

* Changes....: 

* Originally used WNetGetUniversalName, but that 

* doesn't work under Win95 (see KB Q131416). Now uses 

* WNetGetConnection, which uses a string rather than a 

* structure so STRUCTURE_HEADER is now 0. 

lParameters tcMappedPath, tnBufferSize 

* from winnetwk.h 

#define UNIVERSAL_NAME_INFO_LEVEL 0x00000001 

#define REMOTE_NAME_INFO_LEVEL 0x00000002 

* from winerror.h 

#define NO_ERROR 0 

#define ERROR_BAD_DEVICE 1200 

#define ERROR_CONNECTION_UNAVAIL 1201 

#define ERROR_EXTENDED_ERROR 1208 

#define ERROR_MORE_DATA 234 

#define ERROR_NOT_SUPPORTED 50 

#define ERROR_NO_NET_OR_BAD_PATH 1203 

Returning a UNC Path 

from getdir() 

If you pass getdir() an initial folder in UNC format, then that 

folder will be the initially selected folder, but it won’t appear 

in the list of drives in the dialog box (see Figure 1). If that 

folder or one of its subfolders is selected, then the string 

returned will be in UNC. Be careful, though. If you navigate to 

a mapped drive from the drive’s drop-down box, there’s no 

way to get back to the UNC drive. 

#define ERROR_NO_NETWORK 1222 

#define ERROR_NOT_CONNECTED 2250 

* Local decision - paths aren't likely to be longer 

* than this - if they are, this function calls itself 

* recursively with the appropriate buffer size as the 

* second parameter. 

#DEFINE MAX_BUFFER_SIZE 500 

* String length at the beginning of the structure 

* returned before the UNC path. 

* ACC changed to 0 on 9/10/98 - Now using 

* WNetGetConnection, which uses a string rather than a 

* struct. 

#DEFINE STRUCTURE_HEADER 0 

local lcReturnValue 

if type('tcMappedPath') = "C" and ; 

! isnull(tcMappedPath) 

Figure 1. Passing 

getdir() a UNC 

path will initially 

display the UNC 

path in the dialog 

box, but the 

unmapped drive 

won’t appear in 

the drop-down list. 

* Split up the passed path to get just the drive. 

local lcDrive, lcPath 

* Just take the first two characters - we'll put it 

* all back together later. If the first two 

* characters aren't a valid drive, that's okay. The 

* error value returned from the function call will 

* handle it. 

* Case statement ensures we don't get the "cannot 

* access beyond end of string" error. 

do case 

case len(tcMappedPath) > 2 

lcDrive = left(tcMappedPath, 2) 

lcPath = substr(tcMappedPath, 3) 

case len(tcMappedPath)

lcPath = "" 

endcase 

declare INTEGER WNetGetConnection IN WIN32API ; 

STRING @lpLocalPath, ; 

STRING @lpBuffer, ; 

INTEGER @lpBufferSize 

* Set up some variables so the appropriate call can 

* be made. 

local lcLocalPath, lcBuffer, lnBufferSize, ; 

lnResult, lcStructureString 

* Set to +1 to allow for the null terminator. 

lnBufferSize = ; 

iif(pcount() = 1 or ; 

type('tnBufferSize') # "N" or ; 

isnull(tnBufferSize), ; 

MAX_BUFFER_SIZE, ; 

tnBufferSize) + ; 

1 

lcLocalPath = lcDrive 

lcBuffer = space(lnBufferSize) 

* Now call the dll function. 

lnResult = WNetGetConnection(@lcLocalPath, ; 

@lcBuffer, @lnBufferSize) 

do case 

* String translated sucessfully. 

case lnResult = NO_ERROR 

* Actually, this structure-stripping is no longer 

* required because WNetGetConnection() returns a 

* string rather than a struct. 

lcStructureString = alltrim(substr(lcBuffer, ; 

STRUCTURE_HEADER + 1)) 

lcReturnValue = left(lcStructureString, ; 

at(chr(0), lcStructureString) - 1) + lcPath 

* The string pointed to by lpLocalPath is invalid. 

case lnResult = ERROR_BAD_DEVICE 

lcReturnValue = tcMappedPath 

* There's no current connection to the remote 

* device, but there's a remembered (persistent) 

* connection to it. 

case lnResult = ERROR_CONNECTION_UNAVAIL 


* A network-specific error occurred. Use the 

* WNetGetLastError function to obtain a description 

* of the error. 

case lnResult = ERROR_EXTENDED_ERROR 


* The buffer pointed to by lpBuffer is too small. 

* The function sets the variable pointed to by 

* lpBufferSize to the required buffer size. 

case lnResult = ERROR_MORE_DATA 

lcReturnValue = getuncpath(tcMappedPath, ; 

lnBufferSize) 

* None of the providers recognized this local name 

* as having a connection. However, the network is 

* not available for at least one provider to whom 

* the connection may belong. 

case lnResult = ERROR_NO_NET_OR_BAD_PATH 


* There's no network present. 

case lnResult = ERROR_NO_NETWORK 


* The device specified by lpLocalPath isn't 

* redirected. 

case lnResult = ERROR_NOT_CONNECTED 


otherwise 


endcase 

else 



5 

endif 

return lcReturnValue 

Constants from the corresponding API header 

files are reproduced in the function rather than in a 

standalone header to make it more portable, and a 

couple of local constants are also #DEFINEd for clarity 

later in the code. 

The mapped drive parameter is checked, and if it’s 

not a character expression, or if it’s .NULL., then the 

function simply returns whatever was passed to it. If the 

tests are passed, then the API function is DECLAREd. 

Note the use of the Win32API rather than the specific 

MPR.DLL. 

Splitting up the mapped path parameter into its 

component pieces is simply a matter of taking the first 

two characters and calling them the mapped drive, and 

taking the rest of the expression and calling them the 

path. There’s no problem if that’s not a valid assumption 

because the API function will return an error value and 

we’ll take the appropriate action. 

Next I call the API function and check the return 

value. The two important values I’m looking for are 

NO_ERROR (my personal favorite ) and 

ERROR_MORE_DATA. The NO_ERROR code means 

just that: The drive mapping was decoded successfully, 

and the result is in the lcBuffer variable. 

The value placed in lcBuffer is a null-terminated 

string. This means that the string is terminated by a chr(0) 

that needs to be stripped before we use it in VFP. I just 

append the path part of the original mapped path 

parameter to the translated drive returned by the PAI call 

and voila—a UNC version of the mapped path. 

The ERROR_MORE_DATA return value tells me that 

I didn’t allocate enough space in the return buffer, and I 

need to call the function again. Fortunately, once I get this 

error, I no longer need to guess how long to make the 

buffer. In addition to returning the error, the API function 

sets lnBufferSize to the value required so I can call 

GetUNCPath() recursively with the original mapped 

drive path and lnBufferSize. 

Each of the other error states indicates that the 

mapping couldn’t be decoded for some reason or other. 

I’ve decided to treat them all the same way: Simply return 

the mapped path passed to the function. 

While VFP is a wonderful development environment, 

it does have some limitations. Fortunately, it provides 

enough access to the Windows API to be able to work 

around most of them. ▲ 

12COASC2.ZIP at www.pinpub.com/foxtalk 

Andrew Coates is an independent developer/data consultant living in 

the Olympic City—Sydney, Australia. He specializes in PC database 

applications, particularly integrating tools and visualizing spatial data. 

a.coates@civilsolutions.com.au.

Best Practices FoxTalk 

Seeing Patterns: The Mediator 

Jefferey A. Donnici 

This month’s column continues the series that looks at some 

common design patterns and how they can be found and 

used within our Visual FoxPro applications. The pattern 

discussed this month is the Mediator pattern, which allows a 

single object to handle the interaction between a set of other 

objects. In doing so, the set of mediated objects is less 

coupled to one another and can be extended or varied 

independently. To illustrate the Mediator pattern in action, 

two very different examples are given. 

WITH the last Best Practices column, I began a new 

series called “Seeing Patterns.” For those who 

missed that column (for shame!), the intent 

behind this series is to discuss the real-world use of some 

common design patterns, using VFP examples for 

illustration. If you aren’t already familiar with the concept 

of object-oriented design patterns, I encourage you to 

look through the last column for some references and a 

discussion that provides an introduction to the ideas 

behind design patterns. Specifically, you should make 

sure to get a copy of Design Patterns: Elements of Reusable 

Object-Oriented Software by E. Gamma, R. Helm, R. 

Johnson, and J. Vlissides (Addison-Wesley, ISBN 0-201- 

63361-2). This is the most popular of all the patternsrelated 

books, and any developer working with an objectoriented 

language should have it. 

With the introduction to design patterns out of the 

way, I can dive right into this month’s discussion of the 

Mediator pattern. This column provides an introduction 

to the Mediator and, more importantly, some real-life VFP 

examples. Hopefully, the VFP-centric approach to this 

discussion will help you learn to “see” this pattern in 

your own work, thereby making it easier to pull it from 

your “toolbox” when solving a design problem in the 

future. Remember, however, that object-oriented design 

patterns represent another layer of abstraction above the 

design process. As such, the patterns themselves aren’t 

specific to any one programming language or design tool. 

Why the Mediator? 

The purpose of the Mediator pattern is to provide a 

central point for interaction between a set of similar 

objects. By having all interaction in a set of objects go 

through one portion of the component or subsystem, the 

dependencies and coupling between the objects in that set 

are reduced. As explained in Design Patterns, the intent of 


http://www.pinpub.com 

6.0 

the Mediator is to “define an object that encapsulates how 

a set of objects interact. Mediator promotes loose coupling 

by keeping objects from referring to each other explicitly, 

and it lets you vary their interaction accordingly.” 

A good object-oriented design typically has a large 

number of classes in it, simply because behavior and data 

are spread out among the classes to provide cohesion. The 

more a system is comprised of a set of highly specialized 

“pieces,” all working together to provide larger 

functionality, the more those pieces can be reused. On the 

extreme opposite end of the spectrum, a few large classes 

that perform several different functions apiece aren’t 

typically reusable in a different application context. 

The flip side of this design principle, however, is that 

the relationships between (or “the coupling of”) all those 

objects brings with it a higher learning curve for the 

designer and programmer, as well as the potential for 

reduced reusability. If each object in a subsystem must 

know the programmatic interface for all the other objects 

in the subsystem, then the overall reusability of every 

object suffers. So, while a large number of objects in a 

system typically means that they’re inherently more 

cohesive, each new object in the system has the potential 

to increase the number of dependencies exponentially. 

The Mediator provides a solution to this problem by 

acting as a central point of contact for all those intrasystem 

communications. Think of the Mediator as a 

“traffic cop” that makes sure everyone gets through the 

intersection like they should, without anybody having to 

get out of their car and talk to another driver. As long as 

all the “mediatees” (the cars and drivers) are being 

coordinated by the “mediator” (the traffic cop), there isn’t 

any need for the objects (or grumpy drivers) to interact 

with one another (see Figure 1). 

The benefits of this approach are numerous. The 

decoupling of the “mediatees,” called “colleagues” in 

Design Patterns, has been mentioned already, but there are 

others as well. For example, your class hierarchies can be 

less deep because the need to subclass is reduced when 

using a Mediator. The Mediator defines the interaction 

between the pieces of the system, so only the Mediator 

needs to be subclassed when the nature of the 

relationships changes. Each of the classes themselves 

remains the same, with the “translation” between them 

occurring within the Mediator. 

Also, the Mediator simplifies the nature of the

elationships between the objects being mediated. 

Without the Mediator in place, the communications 

between objects would likely take the form of many-tomany 

relationships. With the Mediator, those 

communications become a series of one-to-many 

relationships, which are far easier to understand and 

maintain over the long term. 

It should be noted, however, that the Mediator does 

have one significant drawback. Remember that the goal 

of the Mediator is to simplify the interaction between 

objects. Unfortunately, the Mediator component itself 

often becomes fairly complex internally. In Design 

Patterns, the point is made that the “Mediator pattern 

trades complexity of interaction for complexity in the 

Mediator. Because a Mediator encapsulates protocols, 

it can become more complex than any individual 

colleague. This can make the Mediator itself a monolith 

that’s hard to maintain.” While there isn’t any easy way 

around this potential problem, it’s best to know in 

advance that the Mediator portion of the design might 

require special development considerations. Carefully 

commenting and documenting the relationships that 

have been abstracted from the objects into the Mediator 

will go a long way toward lessening the maintenance 

cost of the Mediator itself. 

Example 1—the Forms Manager 

One of the most common examples of the Mediator 

pattern—and you might already have this in your own 

applications or framework—is a system-wide Forms 

Manager. The purpose of the Forms Manager is to provide 

a centralized point for communicating with, and between, 

the open windows in your application. If, for example, 

you need one form to get a value from another form, or if 

you want to close all open forms in the application, then 

the Forms Manager can handle those requirements. The 

following code is a skeleton example of a Forms Manager 

class, including some ideas on the functionality and 

behavior that it might contain. 

DEFINE CLASS cstFormManager AS Custom 

PROTECTED aForms[1,3] 

PROCEDURE GetFormCount 

IF THIS.NoForms() 

RETURN 0 

ELSE 

RETURN ALEN(THIS.aForms, 1) 

ENDIF 

ENDPROC 

PROCEDURE NoForms 

RETURN (TYPE('THIS.aForms[1, 1]') == 'L') 

ENDPROC 

PROCEDURE FindForm 

LPARAMETERS tuParam1, tcParamType 

*-- The purpose of this method would be to 

*-- allow the developer to pass an object 

*-- reference, a class name, a caption, or 

*-- even an object name as a parameter. 

*-- The second parameter would indicate the 

Figure 1. The Mediator pattern decouples the objects in a system 

so that the relationships between them can be handled in a 

centralized fashion. 

*-- type of variable passed in the first 

*-- parameter. This information would be used 

*-- to find the matching form in the 

*-- collection. If one is found, the row for 

*-- it within the .aForms collection is 

*-- returned. Otherwise, 0 is returned. 

ENDPROC 

PROCEDURE FormExists 

LPARAMETERS tuParm1, tcParamType 

*-- This method uses the FindForm method to 

*-- see whether the indicated form exists. 

*-- Instead of returning a row number, 

*-- however, it just returns a logical 

*-- indicating the existence of the form 

*-- being searched for. 

RETURN (THIS.FindForm(tuParm1,tcParamType)=0) 

ENDPROC 

PROCEDURE AddForm 

*-- This code is provided for illustration 

*-- purposes only. In a production 

*-- environment, you would want to provide 

*-- more exception handling and perhaps other 

*-- "notification" options to indicate that 

*-- a new form has been created. 

LPARAMETERS toForm 

LOCAL lcObjClass,lcObjName,loObject,lnNewRow 

*-- If we don't have an object reference, we 

*-- can't continue the method. Otherwise, 

*-- grab the properties we will 

*-- store in the collection. 

IF TYPE("toForm") # "O" 

RETURN 

ELSE 

loObject = toForm 

lcObjName = loObject.Name 

lcobjClass = loObject.Class 

ENDIF 

*-- If there are no forms, we're putting the 

*-- passed form into the first position in 

*-- the array. 

IF THIS.NoForms() 

lnNewRow = 1 

ELSE 

*-- Otherwise, add a row to the end of the 

*-- array to make room for the passed form. 

lnNewRow = ALEN(THIS.aForms, 1) + 1 

DIMENSION THIS.aForms[lnNewRow,ALEN(THIS.aForms,2)] 

ENDIF 

THIS.aForms[lnNewRow, 1] = lcObjName 

THIS.aForms[lnNewRow, 2] = lcObjClass 


7

THIS.aForms[lnNewRow, 3] = loObject 

RETURN 

ENDPROC 

PROCEDURE RemoveForm 

LPARAMETERS tuParm1, tcParmType 

*-- This method would allow a single form to 

*-- be removed from the collection. The 

*-- first parameter could be an object 

*-- reference, an index position within the 

*-- collection, a form name, or even a caption. 

*-- When the form is removed, the array 

*-- containing the collection would be 

*-- adjusted. If the last form in the 

*-- collection is removed, the first position 

*-- in the collection array would be set to 

*-- .F. to indicate an empty collection. 

ENDPROC 

PROCEDURE RemoveAllForms 

*-- This method would allow all forms to be 

*-- removed from the collection. The 

*-- GetFormCount method would be used 

*-- to determine the number of forms in the 

*-- collection, and this method would iterate 

*-- through them to call the 

*-- .RemoveForm method for each. 

ENDPROC 

PROCEDURE GetFormRef 

LPARAMETERS tuParm1, tcParmType 

*-- This method returns a reference to the 

*-- form indicated by the passed parameters. 

*-- The parameter might be a class name, an 

*-- index position within the collection, 

*-- a caption, or some other form-specific 

*-- property. The FindForm method would be 

*-- used to find the matching form row 

*-- within the collection. If there's no 

*-- matching form found, NULL would be 

*-- returned. 

ENDPROC 

ENDDEFINE 

The idea behind this class definition is that the Forms 

Manager would always be available to the open forms in 

the application. This is often handled by making the 

Forms Manager itself a member of the omnipresent 

“application object.” Because the Forms Manager is 

always available, the forms in the application can add 

themselves to it when instantiating and remove 

themselves from it during the destruction process. For 

example, the following code would be placed into a base 

form class’s Init() event to automate the process of adding 

a new form to the collection: 

oApp.oFormsManager.AddForm(THISFORM) 

When the form is being closed, the following line 

of code in the form’s Destroy() event would prompt 

the Forms Manager to remove the closing form from 

the collection: 

oApp.oFormsManager.RemoveForm(THISFORM) 

Obviously, the preceding example code isn’t a 

complete Forms Manager solution, but it illustrates a 

variety of reasons that a Forms Manager’s functionality 

would be beneficial. Because you could get an object 

reference to any specific form in the collection, you could 

always communicate with the precise form you need in 

any situation. If that form isn’t available, the Forms 

Manager can indicate this as well so that you can 

proceed accordingly. 

Example 2—the dialog box 

Another problem that the Mediator pattern helps to 

solve is the issue of communications between reusable 

containers that are conditionally appearing in yet another 

container. Most dialog boxes contain interface elements 

that are used throughout an application. For example, a 

file-selection dialog box contains a directory list box, but 

the dialog box is hardly the only need for that control. 

Also, dialog boxes usually have controls that turn on/off 

or become enabled/disabled, based on the conditions and 

state of other controls in the dialog box. For example, if 

the user absolutely must choose a file, then the “OK” 

button would be disabled until the user has selected a file. 

Obviously, dealing with all these layers of 

communication can become a problem, especially if the 

same control/container appears in a variety of dialog boxstyle 

interfaces. Enter the Mediator pattern as an elegant 

solution. By providing a single point of interface for all 

the controls in the dialog box, the problem of changing 

the state of other controls becomes centralized. 

The dialog box shown in Figure 2 is a simple example 

of a window that contains three different containers. Each 

of the containers provides a mechanism for setting a value 

to on or off, while only two of them provide a mechanism 

for displaying the current state of that value. 

The key here is that the dialog box can have any 

number of similar containers added to it without a change 

to anything else. That is, none of the other controls in this 

dialog box would require changes, nor would the dialog 

box itself, which is serving as the Mediator component in 

this case. 

Each of the containers in the window has two 

methods that allow it to interact with the dialog box. 

These are UpdateMediator() and SetControls(), which 

respectively communicate with the mediator to reflect a 

change in state and receive messages from the mediator to 

update their member controls. For example, the container 

with the check boxes contains the following 

UpdateMediator() code: 

Figure 2. A simplified dialog box that allows for setting a formwide 

value either on or off. While three of the containers can set 

the value, only two display its current state. 



LPARAMETERS tlValue 

IF PEMSTATUS(THIS.Parent, "UpdateMediator", 5) 

THIS.Parent.UpdateMediator(tlValue) 

ENDIF 

Each of the check boxes calls this method in its 

InteractiveChange() event, passing a logical parameter 

according to its role (“on” or “off”). The container then 

verifies that its parent container has an UpdateMediator() 

method of its own before passing that value up to the 

mediator. This allows the member container to be used in 

other types of Mediator-style designs, as well as in 

designs that don’t require any sort of mediation approach. 

The SetControls() method for each container receives 

the message from the dialog box and updates the controls 

within it. This lets the mediator communicate with each of 

its “mediatees” without having to know the specific 

internals (the type of control) of those containers. Again 

using the check boxes container as an example, here’s the 

SetControls() method: 


*-- Note here that I've changed the 

*-- check boxes to usual boolean values 

*-- instead of numerics. 

THIS.chkOn.Value = (tlValue) 

THIS.chkOff.Value = (NOT tlValue) 

With this functionality in place in each of the 

containers that might appear in the dialog box, we can 

then look at the requirements of the mediator itself. For 

starters, the mediator needs to not only receive the 

messages from its “mediatees,” but it also needs to 

broadcast interpretations of those messages down to them. 

For example, when the user chooses the “off” check box, a 

message is sent up to the mediator to indicate that the 

state is now “off.” A message then needs to be broadcast 

out to the member containers so that they can update 

their own internal state to reflect this change. 

Here are the contents of the dialog box’s 

UpdateMediator() method: 


*-- This is the point at which the 

*-- mediator receives the message from 

*-- one of its member objects and sends 

*-- it to the SetControls method to be 

*-- broadcast down to all other member 

*-- objects. It's here that the one-to- 

*-- many relationship between the mediator 

*-- and its colleagues is leveraged. 

THISFORM.SetControls(tlValue) 

Pretty simple, huh? The truth is that this example is 

straightforward because nothing happens to the value 

that’s received before it’s transmitted back to the member 

containers. It’s a logical value in either case, so we can 

simply pass it through to the SetControls() method of the 

mediator/dialog box. Here’s the content of that method, 

which is only slightly more complex than 

UpdateMediator(): 


FOR EACH loMember IN THIS.Controls 

IF PEMSTATUS(loMember, "SetControls", 5) 

loMember.SetControls(tlValue) 

ENDIF 

ENDFOR && EACH loMember IN THIS.Controls 

THISFORM.Refresh() 

When the SetControls() method receives the 

parameter, it simply loops through its collection of 

member controls and broadcasts the value to each of 

them. Note that it must check for the existence of the 

“SetControls” method before doing the broadcast so that 

calling a non-existent method on the “Close” button 

doesn’t trigger an error. 

“Seeing” the pattern 

It’s important to realize that the “mediator” doesn’t 

always have to be a single class definition, separate from 

the objects being mediated. Remember that the Mediator 

describes a pattern to a design solution, not an actual 

design. As such, I hope you don’t think of the two 

examples I’ve given here, both of which are in this 

month’s Subscriber Downloads at www.pinpub.com/ 

foxtalk, as the only possible types of Mediator designs 

you’ll see. 

For example, you might have a single container class 

that implements a Mediator pattern, using its own 

member controls. The preceding example uses different 

class definitions to illustrate the potential for reusability 

between the mediator and the components it mediates. 

However, suppose you have a form with a variety of text 

boxes and labels that work together as a type of calculator. 

When values are entered into the text boxes, the labels 

might be updated to indicate some calculation of those 

values. In this case, you might not have a need for 

separate container classes. Still, it would be unwieldy 

(and require far too much maintenance) for every text box 

to know how to update the value for every label on the 

form. Instead, you might provide a single method that 

each text box calls when it’s been updated. That method 

could perform the necessary calculations and update the 

label captions accordingly. 

My point is to demonstrate that the Mediator pattern, 

and indeed all patterns, can exist at a variety of levels of 

granularity. While the Forms Manager example is a 

system-wide, global implementation of the Mediator 

pattern, the dialog box example is smaller in scope and 

doesn’t have as wide an effect. A container like the 

“calculator” mentioned previously is even more of a 

“micro” approach to using the Mediator pattern. 

In summary 

Hopefully, these VFP examples of the Mediator pattern 

got you thinking. I’m pretty certain that most of you will 

find examples of the Mediator pattern that already exist in 

Continues on page 14 


9

Mining for Gold in the FFC 

Doug Hennig 

Sometimes you have to sift through a lot of rocks before 

you find true nuggets of gold. Not so with the FoxPro 

Foundation Classes that ship with VFP 6; there’s tons of 

gold in them thar hills. 

ONE of the design goals for VFP 6 was to make it 

easier for programmers new to VFP to get up and 

running with the tool. The Application Wizard is 

one of the results of this goal, and the FoxPro Foundation 

Classes—or FFC—is another. The FFC, located in the FFC 

subdirectory of the VFP home directory, is a collection of 

class libraries that provide a wide range of functions. 

Don’t think that just because previous versions of FoxPro 

have included some, shall we say, less useful (to be polite) 

example files that these fall into that category. While some 

of these do appear to be more demoware than really 

useful, there are still lots of great classes in here. It’s well 

worth the effort to spend some time looking at these 

classes, picking through the rocks to find the nuggets. 

The best way to check out the FFC is using a new VFP 

6 tool called the Component Gallery, accessible from the 

VFP Tools menu. I won’t discuss the features of the 

Component Gallery in this article; it’s simple enough to 

use that you can navigate your way around just by 

playing with it. The FFC classes are displayed in the 

Foundation Classes folder of the Visual FoxPro Catalog 

(when I refer to where classes can be found later in this 

article, I won’t specify this folder or this catalog, just the 

subfolder under Foundation Classes). Classes are grouped 

by type (for example, Buttons, Dialogs, and Utilities) and 

display a description in the status panel when you select 

them. Even better, right-clicking on a class displays a 

context menu giving you access to the Help topic and 

sample files (either to run or to view) for that class. This 

makes it very easy to look through the FFC and see which 

classes might interest you. 

This article will look at some of the FFC classes and 

see how we might use them or even subclass them to 

make them even more useful. Before we get started, 

though, I’ll discuss _BASE.VCX. 

Base classes 

VFP 6 includes a set of subclasses of VFP base classes in 

_BASE.VCX. Although these classes aren’t located in the 

Foundation Classes folder in the Component Gallery 

(they’re in the My Base Classes folder), this VCX is 

Reusable Tools FoxTalk 


http://www.pinpub.com 

6.0 

located in the FFC subdirectory, and all FFC classes are 

subclassed from _BASE classes. If we use FFC classes in 

our applications, _BASE.VCX comes along for the ride. 

So, a question arises: Although this column has been 

developing a robust set of base classes, and many of you 

have your own set, should we consider using _BASE 

classes for our base classes instead? The reason for even 

considering this is, why have two VCXs in our projects 

that provide essentially the same thing? 

After looking at the _BASE classes, the conclusion 

I’ve come to is no; I’ll continue using my own 

SFCTRLS.VCX classes. _BASE classes don’t have the 

visual changes I’ve made to my base classes—for 

example, the AutoSize property for classes such as 

_CheckBox and _Label is set at the default .F.; I almost 

always want it set to .T., so that’s what I’ve done in 

SFCheckBox, SFLabel, and other classes with this 

property. Furthermore, _BASE classes also don’t have 

the behavior I want—for example, their Error methods 

pass the error on to an ON ERROR handler rather than 

using the Chain of Responsibility design pattern (up the 

class hierarchy and then the containership hierarchy) 

that my classes do, as I discussed in my January 1998 

column (see “Error Handling Revisited”). Finally, these 

classes have a lot of custom properties and methods that 

support the Application Wizard. Since I don’t plan to 

use the Application Wizard to create applications, these 

properties and methods would just complicate things. So, 

we’ll just have to live with the fact that _BASE.VCX will 

be included in our projects, whether we want it or not, if 

we use FFC classes. 

_SysToolbars 

It’s highly unlikely you’ll want the VFP development 

environment toolbars (such as the Standard and Database 

toolbars) to be visible when an application is running. 

Unfortunately, there isn’t a single command that hides 

them all, so most developers create an array of toolbar 

names, spin through the array and see whether the 

current toolbar is visible, and, if it is, hide it. Of course, 

you have to do just the opposite when the application 

closes down, at least in a development environment. 

Because this is a common task, the FFC includes a 

class called _SysToolbars; this class is located in 

_APP.VCX and appears as “System Toolbars” in the 

Application subfolder of the Component Gallery. This

class is very simple; it hides and restores the system 

toolbars either automatically or manually. To use it 

automatically, either pass .T. to its Init method when you 

instantiate it programmatically or set its lAutomatic 

property to .T. in the Property Sheet when you drop it on 

a form. In this case, any visible system toolbars are hidden 

when the object is instantiated and redisplayed when it’s 

destroyed. To use it manually, call its HideSystemToolbars 

and ShowSystemToolbars methods. You’ll likely want to 

instantiate it as soon as possible at application startup 

using code similar to this: 

oSysToolbars = newobject('_SysToolbars', '_app.vcx', ; 

'', .T.) 

As long as oSysToolbars stays in scope, the toolbars 

stay hidden. You can either manually release this object or 

let it go out of scope when the application terminates. 

_Resizable 

This class, which is defined in _CONTROLS.VCX and 

appears as “Resize Object” in the User Controls subfolder 

of the Component Gallery, moves and resizes all the 

controls in a form when the form is resized. It takes care 

of all the mundane details of drilling down through 

containers (such as PageFrames), adjusting the Top, Left, 

Height, and Width properties of controls. I’ve done this 

kind of thing manually before in the Resize method of the 

form, writing reams of code to handle all the applicable 

controls. Believe me, anything that can automate this 

tedious chore is very welcome. 

To see how _Resizable works, run the ResizeDemo 

form (by the way, this form also contains an _SysToolbars 

object with lAutomatic set to .T. so you can see how that 

class works). Leave “Resize” unchecked and resize the 

form. See how dumb it looks as more background appears 

when you make the form larger or controls get hidden as 

you make the form smaller? Not the sign of a professional 

application. Now check “Resize” (but leave “SFResizable” 

unchecked for now); when you resize the form, the edit 

box is resized, and the other controls are moved 

automatically. 

However, there are a couple of problems with this 

class. First, it resizes or moves all the controls. Typically, 

when you resize a form, you want to resize certain 

controls (such as edit boxes) and move the ones below 

and to the right of them to account for the new size; the 

rest you want to leave alone. Another problem is that it 

moves everything proportional to the original size of the 

form; the effect is that a resized form looks like a blown 

up or shrunk version of the original, with controls further 

apart or closer together. The result is sort of like what 

happens to writing on a balloon as it’s blown up. In my 

experience, what you really want is a form that looks just 

like it was but with some of the controls larger or smaller 

and the rest just moved relative to the resized controls. 

After all, the whole reason for the user to resize a form is 

to be able to see more of those controls they’d normally 

have to scroll (grids, list boxes, edit boxes, TreeView and 

ListView controls, and so forth), not to get a bigger form 

with more background. 

The good news is that we don’t need to throw 

_Resizable out and create a new class with the behavior 

we want. _Resizable has all of the logic we need; it just 

doesn’t do things quite right. So, let’s subclass it and 

make the subclass act the way we expect. 

The subclass I created is called SFResizable, and it’s 

contained in SFFFC.VCX in the Subscriber Downloads at 

www.pinpub.com/foxtalk. I changed both the Height and 

Width properties to 17 so the control doesn’t take up as 

much space when it’s dropped on a form. Since we need 

to treat some controls differently than others (some will be 

moved, while others might be resized), we need a way to 

indicate how each control should be treated. I originally 

considered adding new properties to my base classes (for 

example, lResize, which, if .T., would indicate that this 

control should be resized) but rejected that because then 

SFResizable would only work with a certain set of base 

classes, and that would make it far less reusable. Instead, I 

decided to make SFResizable self-contained, so I created 

the following new properties: 

• cRepositionLeftList: A comma-delimited list of the 

names of controls that should be moved left-right 

only as the form is resized. 

• cRepositionList: A comma-delimited list of the names 

of controls that should be moved left-right and updown 

as the form is resized. 

• cRepositionTopList: A comma-delimited list of the 

names of controls that should be moved up-down 

only as the form is resized. 

• cResizeList: A comma-delimited list of the names of 

controls that should be resized as the form is resized. 

I also overrode the AddToArray and SetSize 

methods. AddToArray adds size and position information 

about a control to an array property of the class; it’s 

called from the LoopThroughControls method, which 

processes all of the controls in the form. The problem 

with the original AddToArray is that it stores the size and 

position information of the control as values proportional 

to the size and position of the form rather than the actual 

values for the control. So, I simply used the Visual Basic 

method of subclassing (I copied the code from 

_Resizable.AddToArray and pasted it into SFResizable’s 

method) and then modified the code to store the original 

values. SetSize is also called from LoopThroughControls; 

it adjusts the size and position of a control by the 

difference between the original (stored in the 


11

InitialFormHeight and InitialFormWidth properties) and 

current sizes of the form. Since I don’t want every control 

resized and moved, I changed the code to use the 

following logic: 

• If the control’s name is in the cRepositionList 

or cRepositionTopList properties, its Top value 

is adjusted. 

• If the control’s name is in the cRepositionList 

or cRepositionLeftList properties, its Left value 

is adjusted. 

• If the control’s name is in the cResizeList property, 

its Width and, for certain types of controls (Label, 

Editbox, Listbox, Grid, PageFrame, Line, OLEControl, 

OLEBoundControl, Shape, and Container), Height 

values are adjusted. 

To use SFResizable, drop it on a form and call its 

AdjustControls method in the Resize method of the form. 

Enter the names of those controls that should be resized 

as the form is resized into the cResizeList property of the 

SFResizable object; grids, edit boxes, and other controls 

that can scroll are obvious candidates. Enter the names of 

those controls that should be moved up-down and leftright 

as the form is resized into the cRepositionList 

property. For example, controls below and to the right of 

an edit box might qualify for this adjustment. For those 

that should only be moved up and down, enter their 

names into the cRepositionTop property. Examples 

include controls below a grid, because these controls need 

to move up or down as the grid’s Height is changed. 

Finally, enter the names of controls that should be moved 

left and right, such as those to the right of an edit box, as 

the form is resized into the cRepositionLeft property. 

Run the ResizeDemo form again, but this time check 

both “Resize” and “SFResizable”. When you resize the 

form, the text box beside “Label 1” doesn’t move; the edit 

box and shape surrounding it don’t move but are resized; 

the “Resize” and “SFResizable” check boxes and the check 

boxes beside the edit box move left and right but not up 

and down; the text box beside “Label 2” moves up and 

down but not left and right; and the “Reset” button 

moves both up-down and left-right. In other words, the 

form behaves as we’d expect when it’s resized. 

A perfect addition to SFResizable would be a builder 

to make it easy to specify which controls should be moved 

or resized, with perhaps a list of the controls in the form 

and check boxes indicating how the selected control 

should be treated. 

Registry 

As you know, the Registry is the “in” place to store 

configuration, preference, and other application settings; 

INI files are officially passe (although I know lots of 

developers who, like me, would rather lead a user 

through editing an INI file over the phone than dare 

have them use a tool like REGEDIT). Settings should 

normally be stored in keys with a path similar to 

HKEY_CURRENT_USER\Software\My Company 

Name\My Application\Version 1.1\Options. 

The FFC Registry class (defined in REGISTRY.VCX 

and appearing as “Registry Access” in the Utilities 

subfolder of the Component Gallery) is a wrapper class 

for the Windows API calls that deal with the Registry. 

Rather than having to know that you must open a key 

using the RegOpenKey function before you can use 

RegQueryValueEx to read the key’s value, all you have 

to know with the Registry class is that you call its 

GetRegKey method. Here’s an example that gets the 

name of the VFP resource file: 

#include REGISTRY.H && located in HOME() + 'FFC' 

loRegistry = newobject('Registry', 'Registry.vcx') 

lcResource = '' 

loRegistry.GetRegKey('ResourceTo', @lcResource, ; 

'Software\Microsoft\VisualFoxPro\6.0\Options', ; 

HKEY_CURRENT_USER) 

(Yeah, I know it’s easier to use SET(‘RESOURCE’, 1), but 

this is just an example.) 

REGISTRY.VCX also contains subclasses of Registry 

that make it easier to read and write VFP settings 

(FoxReg), ODBC settings (ODBCReg), applications by 

file extension (FileReg), and even (horrors!) INI files 

(OldINIReg). Registry-specific constants are defined in 

REGISTRY.H so you can specify HKEY_CURRENT_USER 

(as I did in the preceding code) rather than its value 

(-2147483647). 

Here are the useful methods in REGISTRY.VCX. 

Unless otherwise specified, all return a code indicating 

success (0, or the constant ERROR_SUCCESS) or the 

WinAPI error code; see REGISTRY.H for error codes. 

• GetRegKey: Puts the value of the specified key 

into a variable. 

• SetRegKey: Sets the value of the specified key to the 

specified value (the entire key path is created if it 

doesn’t exist). 

• DeleteKey: Deletes the specified key (and all subkeys) 

from the Registry. 

• DeleteKeyValue: Removes the value from the 

specified key. 

• EnumOptions: Populates an array with all the 

settings under a specific key and their current values. 

• IsKey: Returns .T. if the specified key exists. 

Registry can be instantiated at application startup 

(perhaps by an Application object) to get the settings the 



application needs: location of the data files on a LAN, 

names of the most recently used forms (so they can 

appear at the bottom of the File menu like Microsoft 

applications do), and so forth. It can also be dropped on a 

form to save and restore form-specific settings such as the 

Left, Top, Height, and Width values (so it has the same 

size and position as when this user closed it), grid column 

widths and positions (so users can rearrange grids and 

have them appear that way the next time), and so on. 

Being a picky guy, I have two problems with the 

Registry class. First, because the return value of 

GetRegKey is a success or error code, you have to pass the 

variable you want the value placed into by reference. I’d 

prefer it to return the value of the key; after all, if an error 

occurs, the WinAPI error code is probably as useful to me 

as the “details” section of a GPF dialog, and even if I do 

want it, it could easily be stored in a property of Registry 

I can query. Second, it’s likely that both the key path 

(“Software\Microsoft\VisualFoxPro\6.0\Options” in 

the previous example) and the user key (usually 

HKEY_CURRENT_USER) are going to be the same for 

every method call of a specific instance of a Registry 

object. Being the lazy sort, I’d rather put these values into 

properties and not pass them every time I call a method. 

As with _Resizable, I’ve subclassed Registry into 

SFRegistry (also in SFFFC.VCX) to have the behavior I 

want. Although I planned to, it turned out that I didn’t 

have to add properties for the default key path 

(cAppKeyPath) and user key (nUserKey)—they already 

existed, even though they’re not used by Registry 

(they’re used by the subclasses in REGISTRY.VCX). Since 

Registry.Init sets nUserKey to HKEY_CURRENT_USER, 

there normally isn’t even a need to change this property. 

I changed the GetRegKey, SetRegKey, DeleteKey, 

DeleteKeyValue, EnumOptions, and IsKey methods to 

accept different parameters than the matching Registry 

class methods (I rearranged the parameters so optional 

ones are at the end) and return a more appropriate value 

(the key value in the case of GetRegKey, the number of 

options in the array in the case of EnumOptions, and .T. 

if the method succeeded in the case of SetRegKey, 

DeleteKey, and DeleteKeyValue). These methods also 

store the WinAPI result code into a new nResult property, 

which can be used to determine what went wrong if a 

method fails. Here’s an example; this is the code from 

EnumOptions: 

lparameters taRegOptions, ; 

tlEnumKeys, ; 

tcKeyPath, ; 

tnUserKey 

local lcKeyPath, ; 

lnUserKey, ; 

lnReturn 

* If the key path and user key weren't passed, use the 

* defaults. 

lcKeyPath = This.GetKeyPath(tcKeyPath) 

lnUserKey = This.GetUserKey(tnUserKey) 

* Use the parent class method to enumerate the key, 

* store the result code, and return the number of 

* options it found. 

lnSuccess = dodefault(@taRegOptions, lcKeyPath, ; 

lnUserKey, tlEnumKeys) 

This.nResult = lnSuccess 

lnReturn = iif(lnSuccess = ERROR_SUCCESS, ; 

alen(taRegOptions, 1), 0) 

return lnReturn 

GetKeyPath and GetUserKey are new methods 

called by all the overridden methods to either use the 

key path and user key values passed, or the defaults 

(stored in the cAppPathKey and nUserKey properties) 

if they weren’t passed. 

Here’s an example of the use of SFRegistry; this code 

would be used in the Init method of a form to restore the 

size and position it had the last time the user had it open. 

This code assumes that an SFRegistry object named 

oRegistry was dropped on the form and its cAppPathKey 

property was set in the Property Sheet to the key path for 

this application. 

lcKey = This.oRegistry.cAppPathKey + '\' + This.Name 

lcTop = This.oRegistry.GetRegKey('Top', lcKey) 

This.Top = iif(isnull(lcTop), This.Top, val(lcTop)) 

* similar code for Left, Width, and Height 

(Since the Registry class only supports reading and 

writing strings, VAL() must be used on the return 

value. Also, if this is the first time this form is run, a 

key might not exist for it in the Registry, in which case 

.NULL. is returned, so this code handles that case.) 

A method of the form (such as Release) would use 

This.oRegistry.SetRegKey to save the current form size 

and position in the Registry. 

For another example, run REGISTRYDEMO.PRG. It 

creates some new keys, displays their values, and shows 

how EnumOptions works. (It also deletes the keys it 

creates so it doesn’t pollute your Registry permanently.) 

_ObjectState 

If you’ve been doing your homework on design patterns, 

you’re probably aware of a pattern known as Memento. 

A Memento is intended to save the state of something, 

presumably so it can be restored after it’s been changed. 

The FFC includes a class called _ObjectState that’s sort 

of like a Memento: It saves the value of one or more 

properties of another object and can later restore them to 

their former values. 

_ObjectState is defined in _APP.VCX and appears as 

“Object State” in the Application subfolder in the 

Component Gallery. It has an oObject property that 

contains an object reference to the object whose state it 

maintains; this property can be set by passing the object 

reference to the Init method of the _ObjectState object or 

by setting it manually. It has a Set method that sets the 

value of the specified property of the managed object to 

the specified value, optionally first saving the original 


13

value in an array property of itself. It also has a Restore 

method that restores the value of one or all saved 

properties. The Restore method is also called from the 

Destroy method, so when the _ObjectState object goes out 

of scope, everything is restored automatically. Since the 

array property has a single row for each saved property, 

you can’t use this class to provide multiple levels of undo; 

however, you could subclass _ObjectState and add this 

behavior if desired. 

Where might we use such a class? One situation 

involves things a user can change but might want to 

change back. For example, you might allow a user to 

rearrange and resize the columns in a grid, but provide a 

“Reset to Default” function that puts them back. Another 

place would be when you temporarily change the 

properties of an object (perhaps so it behaves differently), 

do something with the object, and then change them back 

again. Rather than having a set of local variables that save 

the property values and then having to manually restore 

them before the routine ends, you could do something 

like this: 

local loObjectState 

loObjectState = newobject('_ObjectState', '_app.vcx', ; 

'', This) 

loObjectState.Set('

ActiveX and Automation Review FoxTalk 

Integrating ADO and 

Visual Basic into Your VFP 

Applications, Part 2 

John V. Petersen 

In Part 1 of this series in the October issue, John introduced 

you to some basic (no pun intended ) techniques with 

regard to integrating ADO and Visual Basic into your Visual 

FoxPro applications. ADO offers unprecedented ways in which 

to both access and move data on both an intra- and interapplication 

basis. Visual Basic, with its ability to create ActiveX 

controls, provides an indispensable mechanism for packing 

visual application components that can be reused in any 

application—whether it’s written in VFP, VB, or any other 

environment capable of hosting ActiveX controls. This month, 

John concludes this discussion by expanding and refining the 

design started in October. 

IN Part 1 of this series in the October issue, I showed 

you how to build a Visual Basic ActiveX control that 

encapsulated two things: 

• The Microsoft OLE-DB DataGrid, version 6.0 

• The Microsoft ActiveX Data Objects Library, 

version 2.0 

The DataGrid itself is an ActiveX control. ADO is a 

set of COM objects used to access and update data, which 

can be stored in a variety of formats—either relational or 

non-relational. For more details on what makes up ADO, 

please refer to Part 1 of this series. 

The functionality of the ActiveX control was very 

simple. ADO RecordSet and Connection objects were 

created, and the DataGrid’s DataSource property was 

assigned the reference of the newly created RecordSet 

object. This allowed the contents of the RecordSet object 

to be displayed in the grid. 

Why is it necessary to create what’s essentially an 

ActiveX control of an ActiveX control? Visual Basic 

possesses a couple of important capabilities that VFP 

doesn’t currently support natively: 

• ActiveX data binding 

• The ability to surface COM events 

Currently, inside of VFP, an ADO RecordSet can’t be 

bound to the DataSource property of a DataGrid ActiveX 

control. Further, when ADO objects such as the 


15 

6.0 

Connection and RecordSet are created in VFP, the 

properties and methods of those interfaces are exposed. 

However, VFP doesn’t have the ability to respond to 

events raised by the Connection, RecordSet, or any COM 

object created through the CreateObject function. The 

only way to have events surfaced in VFP is to create an 

ActiveX control. 

Limitations with the current solution 

Several limitations exist with the current solution: 

• Too much functionality—The functionality of creating 

the ADO objects and the presentation services offered 

by the DataGrid are bundled together. Ideally, these 

two items should be split into separate controls to 

provide the most functionality. There will be times 

when the services of ADO will be required—without 

the need to display data in a grid. 

• No public interfaces exist to make the data source 

configurable—The control is currently hard-wired to 

only fetch data from the authors table of the SQL 

Server Pubs database. 

• Surfaced events are private to the control—These events 

need to be surfaced at the ActiveX control interface so 

the host application—VFP, in this case—can recognize 

the occurrence of these events. 

What you need to work through the sample code 

Here’s what you need to work through these examples: 

• ADO 2.0 

• OLE-DB Provider for SQL Server (ships with 

ADO 2.0) 

• OLE-DB Grid ActiveX control, version 6.0 

• SQL Server 6.5 or 7.0 

• Visual Basic 5.0 SP 3 or Visual Basic 6.0 

• Visual FoxPro 6.0 

ADO 2.0 ships with Visual Studio 6. You can 

also obtain ADO via a download from http:// 

www.microsoft.com/data.

Improving the interface 

Figure 1 illustrates the new Visual Basic project. 

The first order of business is addressing the first 

limitation of too much functionality (yes, I know that 

sounds funny). The following code is associated with the 

grid control. Most of the code deals with the visual 

characteristics of the grid—location and size. The most 

important method is the SetDataSource Member. 

Remember, in VFP, an ADO RecordSet can’t be bound to 

the DataGrid control. This is how you can get around that 

limitation. Pass the ADO RecordSet to the control, and 

have the control do the binding for you within its 

boundaries! It works like a charm. 

Private Sub UserControl_Initialize() 

'When the control is dropped onto the form, 

'the grid must be positioned in the upper- 

'left corner of the container. 

With DataGrid 

.Left = 0 

.Top = 0 

End With 

End Sub 

Private Sub UserControl_Resize() 

'When the container is resized, we want the 

'grid to also resize. 

With DataGrid 

.Width = ScaleWidth 

.Height = ScaleHeight 

End With 

End Sub 

'WARNING! DO NOT REMOVE OR MODIFY 

'THE FOLLOWING COMMENTED LINES! 

'MemberInfo=14 

Public Sub SetDataSource(recordset As ADODB.recordset) 

Set DataGrid.DataSource = recordset 

End Sub 

With this design, the services of our grid control 

are very granular. Its only purpose is to accept an 

ADO RecordSet and display the data. We’ll reserve the 

more complicated tasks of responding to events for 

another control. 

The other control in the Visual Basic project consists 

of one user interface element—a Label control. There’s 

quite a lot of code behind this control—far too much to 

Figure 1. The new Visual Basic ActiveX control project contains 

two ActiveX controls. 

print in its entirety. However, I’ll highlight the most 

important pieces of code. 

Going back to the limitations of the first design, no 

public interfaces existed to make the ADO DataSource 

variable. Also, all of the events in the previous design 

were private. This meant that while the control within its 

boundaries recognized the event, no mechanism existed 

for the control to surface those events to its own interface. 

This means that any application environment hosting the 

control wouldn’t have the ability to have its own code 

execute when those events have fired. After all, that’s 

what it’s all about—having the ability to attach VFP code 

to ADO events. 

The first lines of code in the VB ActiveX control 

are as follows: 

Dim WithEvents oconn As ADODB.Connection 

Dim WithEvents ors As ADODB.recordset 

This provides that ability to the ActiveX control to 

respond to events that each of these objects will fire. The 

previous design took advantage of this ability and 

attached Visual Basic code to those events. In the old 

design, when an ADO connection was established, a 

MessageBox dialog box appeared, stating that the ADO 

connection was complete. While not very useful, it served 

to illustrate how events could be trapped. Visual Basic 

code is nice, but we work in VFP. We need the ability to 

surface these events so that VFP code can be used. 

Custom events 

Remember when VFP 3.0 was released back in 1995? We 

were given the ability to define our own methods and 

properties. Defining events, on the other hand, was 

something that wasn’t—and still isn’t—-provided. I, for 

one, didn’t see the big deal in this. After all, there are 

hundreds of events already defined. Why would I need 

more? As you’ll see, the ability to define custom events is 

a very powerful capability. 

To illustrate the power of events, I’ll focus on the 

MoveComplete event of the ADO RecordSet object. This 

event fires whenever the record changes. This event gets 

fired as a result of invoking the MoveFirst, MovePrevious, 

MoveNext, or MoveLast methods. The MoveComplete 

event also fires when an ADO RecordSet is first opened. 

Before looking at the custom event, let’s take a look at 

the code for the internal event that gets fired: 

Private Sub ors_MoveComplete( _ 

ByVal adReason As ADODB.EventReasonEnum, _ 

ByVal pError As ADODB.Error, _ 

adStatus As ADODB.EventStatusEnum, _ 

ByVal pRecordset As ADODB.recordset) 

RaiseEvent movecomplete(adReason, pError, _ 

adStatusCancel, pRecordset) 

End Sub 

In this code, the internal ors_RecordSet object 

variable will respond to the MoveComplete event. This 

code block, in turn, will fire. The code to key on is the 

RaiseEvent statement. Notice that another MoveComplete 



event is being fired, and the arguments passed to the 

internal event are being passed as well. What’s going 

on here? 

In this new design, a public event has been created 

for each of the internal events. To keep things consistent, 

the same name was used. The following line of code in the 

Visual Basic control defines the event: 

Event MoveComplete( _ 

ByVal adReason As ADODB.EventReasonEnum, _ 

ByVal pError As ADODB.Error, _ 

adStatus As ADODB.EventStatusEnum, _ 

ByVal pRecordset As ADODB.recordset) 

There are 11 events for the ADO RecordSet object. The 

new ActiveX control has 11 custom events that correspond 

to each to each of the RecordSet events that will get fired 

internally. In addition to surfacing events, three public 

properties were created as well. These properties are: 

• Provider—This specifies the name of the OLE-DB 

provider to use. 

• ConnectionString—This specifies the connection 

string used to create an active ADO connection. 

• RecordSetSource—This specifies the source of the 

data contained in an ADO RecordSet. This source 

could be the name of a table or a SQL statement. 

Finally, two public methods exist that do the work of 

creating both the ADO connection and RecordSet objects. 

These methods are: 

• CreateConnection—This method uses the Provider 

and ConnectionString properties to establish an 

ADO connection. 

• CreateRecordSet—This method uses both the 

Connection object created by the CreateConnection 

Figure 2. The new Visual Basic ActiveX controls must be 

registered for use in VFP. 

method and the RecordSetSource property to 

establish the ADO RecordSet object. 

With a new design, it’s time to host the controls 

in VFP. 

Hosting the controls in VFP 

Before you can use the controls, they must be registered in 

VFP. Figure 2 shows how the entries will appear in the 

Tool\Options\Controls dialog box. 

Figure 3 illustrates the VFP form used to host these 

new controls. 

The following code in the Init event of the form 

initializes the controls to both get and display data: 

Local connstring 

connstring = "Persist Security Info=False;" 

connstring = connstring ; 

+ "User ID=sa;Initial Catalog=pubs;" 

connstring = connstring + "Data Source=(local)" 

With This.vbADO 

.Provider = "SQLOLEDB.1" 

.ConnectionString = connstring 

.RecordSetSource = "authors" 

.CreateConnection 

.CreateRecordset 

EndWith 

With This 

.ors = This.vbADO.adorecordset 

.oconn = This.vbADO.adoconnection 

EndWith 

This.vbgrid.SetDataSource(This.ors) 

Figure 4 illustrates the VFP form in action. 

So then, where do the events fit in? The following 

code is contained in the MoveComplete event of the 

vbADO ActiveX control: 

*** ActiveX Control Event *** 

LPARAMETERS adreason, perror, adstatus, precordset 

Thisform.tmrRefresh.Enabled = .T. 

Whenever the MoveComplete event fires, 

the tmrRefresh object on the form is enabled. The 

following code is contained in the Timer event of the 

Figure 3. The new Visual Basic ActiveX controls hosted by 

a VFP form. 


17

tmrRefresh object: 

ThisForm.Refresh 

This.Enabled = .F. 

To help make the point clearer, the following is the 

code for the cmdNext CommandButton: 

ThisForm.ors.MoveNext 

Did you notice that a call to the Refresh method of the 

form isn’t present in the CommandButton? The same is 

true for the other navigation buttons as well. What does 

this mean? It means that code only has to exist in one 

location. The alternative is to have method calls in 

multiple locations. Since the COM events aren’t surfaced 

in VFP, this is usually a required course of action. With the 

ability to both recognize events and attach VFP code to 

those events, refresh code only has to be written once 

and, most importantly, only called from one location: the 

MoveComplete event. What’s the benefit? Whether you 

navigate via a CommandButton or the DataGrid control, 

the MoveComplete event will fire. The form will refresh. 

Clearly, this is a much better design—especially from a 

code maintenance standpoint. 

At this point, you might be asking, why the Timer 

Control? I had problems calling the Refresh method 

directly in the event. To avoid errors and get the correct 

functionality, the Refresh method had to be called after 

the MoveComplete event fired. At this point, I don’t 

know what’s causing the problem. I’ll be reporting this 

to the VFP team at Microsoft and will report back on 

their response. 

A quick word on the _VFP AutoYield property 

By default, the AutoYield property of the _VFP object is 

set to .T. This means that VFP will automatically process 

pending Windows events that occur between the 

execution of VFP program code. For this solution to work 

properly, you must be sure that the AutoYield Property is 

set to .F. Otherwise, the events will never be surfaced in 

VFP. This task is taken care of in the Load event of the 

form. The AutoYield setting is reset to the default in the 

Destroy event. 

Conclusion 

Once again, the joining of VFP, Visual Basic, and ADO 

can prove to be a powerful combination. Using a Visual 

Basic-created ActiveX control provides a way to bring 

functionality that doesn’t exist in VFP. For this reason, 

it’s more important than ever to go beyond VFP and give 

serious consideration to the other tools Visual Studio 

has to offer. 

Language aside, this article brings to light issues 

to ponder when considering a design. Clearly, when 

possible, make use of events to centralize code—as 

opposed to making redundant method calls. From a 

maintenance standpoint, you’ll definitely save yourself 

Figure 4. The live VFP form implementing the two 

ActiveX controls. 

a lot of work. 

Finally, I want to take this opportunity to thank my 

writing partner and friend Rod Paddock for being a great 

sounding board for this article. This is definitely new and 

uncharted territory. Rod’s assistance was invaluable when 

I needed to negotiate the rough spots. ▲ 

12PETERS.ZIP at www.pinpub.com/foxtalk 

John V. Petersen, MBA, is vice president of IDT Marketing Systems and 

Services, a Philadelphia-based marketing database consulting firm. John 

has presented at numerous developer conferences, including DevCon 97, 

Tech-Ed, and the Southwest Visual FoxPro Conference. John is a Microsoft 

Most Valuable Professional (MVP) and a co-author of Developing Visual 

FoxPro 5.0 Enterprise Applications and Hands-On Visual Basic 5—Web 

Development, both from Prima Publishing. j_petersen@idtmarketing.com. 



Second Star on the Right 

and Straight on ’til Morning 

Paul Maskens and Andy Kramek 

This month, Paul and Andy take a look at naming and 

object referencing. 

Paul: I was reading through threads on CompuServe 

recently and picked up a few ideas from there, things that 

seem to be causing people trouble, that we can deal with 

here. There appears to be a general confusion about where 

to put the code in a VFP application and how to refer to 

the user interface controls in that code. The power and 

flexibility of VFP doesn’t help either, as there’s no one 

right way to do things. 

Andy: Let’s start with naming and referencing in this 

column. We’ll worry about where to put the code next 

time. The first thing is to give things meaningful names. 

Imagine a form with 25 text boxes named Text1 to Text30 

randomly (with some numbers missing, of course). 

Paul: I don’t have to imagine it, I’ve seen it! Not only that, 

but every form in the application had a Name of “Form1,” 

which didn’t make life any easier. 

Andy: So here’s a guideline for you, then. Name your 

forms with the same name as their SCX (that has to be 

unique within the application anyway), and add to your 

basic form class a Label named lblFormName that has in its 

INIT() method THIS.caption = THISFORM.Name. Now 

whenever you run your form, you have a little label 

showing the actual name of the form, and when the user 

encounters an error, he or she can tell you which form the 

error was in, with a name that means something to you. 

Paul: You’re presuming that we use a form class, of 

course. (We ought to return to that point some time, too.) 

For now, can we just assume things are simple? Even 

using VFP base classes, as many beginners do. 

For example, take a form with a text box and a 

Command button. We’re obviously agreed that the first 

thing is to give them names so you can refer to them. 

Accepting the VFP default of Form1, Text1, and 

Command1 isn’t going to be very helpful in the long 

term! So once they have names like frmCustomer, 

txtName, and cmdSearch, the function of this form and 

the controls on it begin to be self-explanatory. 

The Kit Box FoxTalk 

Andy: I would emphasize that using names isn’t a 

substitute for adding comments, no matter how clear 

those names are! 


19 

6.0 

Paul: Yes! There’s a much under-used form property 

named Comment in the VFP base class. Like the Tag 

property, this property is never addressed directly by VFP 

itself. It’s entirely for developer use. Typically, Comment 

is for, well, comments, and Tag is for data. 

I want to keep this simple, so let’s have the button 

change the background color of the text box. Now we 

have a form named frmDemo. No, er, it’s the first demo of 

many. So let’s try frmDemo1. Whoops, we’re back to the 

Text1-Text30 problem described earlier. Uh, how about 

frmColourChangingDemo? 

Andy: See, naming things is harder than writing the code! 

Just call it frmColChg—that means we don’t need to argue 

about how to spell “color.” 

Paul: Okay, so following on from that, we could have 

cmdChgCol to change the color, and txtShoCol that shows 

the color change. The code is really easy now. In the 

Click() event of cmdChgCol, it’s just one line of code: 

THISFORM.txtShoCol.backcolor = RGB(255,0,0). 

Andy: That’s fine. It’s an example of indirect referencing 

that will work as long as both objects are on the form. 

Now how about making this very useful tool reusable by 

creating a class and putting the class on the form instead 

of the individual controls. Just select both of the controls 

and choose Save As Class from the File menu. Name the 

class and the library to store it in. Then delete the controls 

and add an instance of the new class to the form. 

Paul: What about the name of this new class? And 

what’s the name of this class’s instance on the form? I 

reckon cntChgCol is pretty good for the class, and to make 

matters a little confusing, I think it’s a good name for the 

instance, too. 

Oh! Once I did that, everything fell apart, though. 

Running the form produces an “Unknown member 

‘txtShoCol’ (Error 1925)”. I know it’s there—I can see it, 

and its name is still txtShoCol in the form designer. But

there’s now a container in the way, so there isn’t a 

txtShoCol object on the form anymore. Instead it’s 

contained in the cntChgCol, which is on the form, so the 

reference now has to be THISFORM.cntChgCol.txtShoCol 

instead. 

Andy: Or even better, use THIS.Parent.txtShoCol instead. 

In fact, that’s what you probably should have done the 

first time, planning ahead in case the group of controls 

was going to be reused in a container class, or you were 

going to add them to a Page Frame to the form. 

Paul: That reminds me—in MS Knowledge Base article 

Q155013, there’s a text box in a column of a grid in a 

container that’s doing an incremental search. In the 

KeyPress event, there’s a line of code that seems a 

little excessive: 

THIS.Parent.Parent.Parent.Search( nKeyCode ) 

I can work out what it’s doing—the Search() method 

is a method of the container, and this is passing the 

keystroke to it, but that’s not very clear, is it? It’s unlikely 

to be broken when it’s reused, because the article is about 

building a custom control. 

Andy: So what are you suggesting? In that particular case, 

I don’t see that there’s any alternative. The referencing has 

to be relative, because the text box can’t possibly know 

what the name of the outermost container will be at 

runtime. There’s no “THISCONTAINER” reference, and 

anything relative to “THISFORM” is obviously not 

applicable. It’s not pretty, but I don’t see what else you 

can do. 

Paul: Well, what I’d do is create a ThisContainer reference. 

Either as a property if I’m using a class, which is set to 

THIS.Parent.Parent.Parent in the INIT() method, or as a 

LOCAL variable that has to be set every time the 

KeyPress method is called (and therefore is of little 

benefit). There’s a marginal benefit in the latter 

approach, because the reference is also used in 

THIS.Parent.Parent.Parent.Pop() in the same method 

where the variable can be used as well. 

Andy: I see. So you’re proposing to replace this: 

IF nKeyCode = 13 && They hit the ENTER key 

This.Parent.Parent.Parent.Pop() 

ENDIF 

IF (nKeyCode > 48 AND nKeyCode < 58) OR ; 

(nKeyCode > 64 AND nKeyCode < 123) 

** Calls the search method if you hit a 

** letter or numeric key. 

This.Parent.Parent.Parent.Search(nKeyCode) 

ENDIF 

with this: 

LOCAL loThisContainer 

loThisContainer = This.Parent.Parent.Parent 


loThisContainer.Pop() 

ENDIF 




** letter or numeric key. 

loThisContainer.Search(nKeyCode) 

ENDIF 

As you say, the speed benefit is marginal, but the 

code is now much more readable and hence easier to 

maintain. I’m wondering why use a LOCAL variable 

if you can’t create a property, when you could use a 

PUBLIC variable to simulate the property and initialize 

it by placing goThisContainer = THIS in the container’s 

INIT() method. 

Paul: Aaargh! Splutter, cough . . . You’re playing devil’s 

advocate, aren’t you? Well, since there can be only one 

global variable, you’ll run into problems if your forms are 

modeless and can have multiple instances open in the 

application at a time—or even if you adopt this technique 

in every container class and just have two or more 

containers on the same form. 

Andy: All right! I give in; even though my forms would 

probably be modal anyway, the second reason is the 

clincher. (Just testing .) 



Paul: I could have used WITH ... ENDWITH instead of 

creating a variable, like this: 

WITH This.Parent.Parent.Parent 


.Pop() 

ENDIF 




** letter or numeric key 

.Search(nKeyCode) 

ENDIF 

ENDWITH 

But that doesn’t make it any more legible. By the time 

I’m reading that second .Search() method call, it’s easy to 

forget where that method is. Besides, I find that leaving 

off the leading period is the smallest, hardest to find, most 

catastrophic typing mistake that I regularly make. 

Andy: So can we derive a general rule here? How about 

this: Multiple layers of referencing should be resolved as few 

times as possible, preferably only once. 

Paul: I’d add that in doing so you should keep the 

code readable, either by commenting it properly 

(Andy: shocked gasp!) or using a self-documenting 

object reference. 

Andy: That’s all very well for your simple example, but in 

real life things are a lot more complicated. In order to 

send messages between objects, you have to know their 

relative positions in the object hierarchy so that you can 

work out the addressing properly. 

Paul: What exactly do you mean by the “object 

hierarchy”? I’m familiar with the “class hierarchy,” 

which defines the inheritance relationship, but I’m not 

quite sure what you mean by the object hierarchy. 

Andy: Well, I guess another name for it is the 

“containership hierarchy”—though I don’t really like the 

term because it implies that it deals with “containers” 

specifically, whereas we’re talking about all objects, 

whether they’re in containers or not. It refers to the 

relative positions of objects within the principal container 

(typically the Form) and describes the relationships 

between them. In order to reference one object from 

another, you need only determine the position of each in 

the hierarchy to be able to work out how to pass a 

message between the two. This is easier to illustrate than 

to explain, so take a look at the form shown in Figure 1. 

Paul: Okay, I call it the containership hierarchy because I 

usually need to use it when I’m messing with containers. 

That form looks pretty standard (though I wouldn’t have 

laid it out that way ); what’s your point? 

Figure 1. Sample contact manager form. 

Andy: Well, this form is constructed from a mixture of 

classes and individual objects, so the messaging gets 

pretty complex. For example, the “Personal Mobile Phone 

Number” field is named txtPersMobi, but it’s not a direct 

member of the form. It’s actually contained in an object 

derived from the class cntFullAdd, which is itself a 

composite class made up of two other classes—cntAddress 

and cntContact—and the field in question is defined as a 

member of the latter. 

Paul: Hmm, I think I see what you’re getting at. The 

address to get that field’s value is actually going to be: 

ThisForm.cntFullAdd.cntContact.txtPersMobi.Value 

But it’s not exactly obvious, is it? 

Andy: Precisely! Especially when you consider that the 

Find button actually is a direct member of the form (its 

apparent container is actually just a “shape” object), 

whereas the Save button is a member of the cntFormMode 

class. Okay, I admit this is a pretty contrived illustration, 

but I’ve seen more errors and “bugs” in my own (and 

other people’s) code because the object hierarchy isn’t 

properly understood than I care to think of. 

Paul: Oh, I don’t know that it’s all that contrived. I’ve seen 

plenty of examples of forms that mix things up like this, 

and yes, I agree, it’s always a problem trying to work out 

how things relate—especially if you didn’t do the work 

yourself in the first place. I assume you have a solution, 

since you’re raising the question? 

Andy: Yes, I have. It’s really terribly simple and yet again 

illustrates how object-oriented programming reflects the 

real world. See if you can guess it—after all, what we’re 

talking about is how to ensure that someone who wants to 

navigate within your form doesn’t get lost. What would 


21

you do to ensure that I don’t get lost when I’m coming to 

your new offices for the very first time? 

Paul: Easy, draw you a map! 

Andy: Give the man a cigar! So why don’t we apply this 

solution to this case? Figure 2 shows a map of the object 

hierarchy for the form shown previously. 

Paul: That’s pretty neat. It’s just a standard Organization 

Chart, isn’t it? It looks rather like the Object model 

diagrams that MS produces for what used to be OLE 

Automation (I can’t remember what it’s called this week). 

Andy: Yes, it was produced using the MS Organization 

Chart 2.0 add-on that ships with Office, and you can use 

it to work out how to reference things correctly. All you 

need to do is start “walking” from the initial object 

(“This”) toward the object you want to address. Each 

time you meet a shaded object, you must add that to 

the address—using “Parent” if you’re climbing up the 

tree, and the object’s name if you’re 

going down. 

Paul: Okay—let’s suppose I want the 

Save button to read the person’s 

“Known As” name. I start from the 

button with ‘This’, then move 

upwards and find myself at the 

cntFormMode object, which is shaded, 

so I add a parent reference to get 

‘This.Parent’. 

Carrying on upwards, I reach the 

form object (also shaded, so I need 

another “parent”) and get 

‘This.Parent.Parent’ before starting 

downwards again to arrive at 

cntName—which just gets added: 

‘This.Parent.Parent.cntName’. Finally, 

I reach the target text box, so my full 

address (for the Value property) is 

‘This.Parent.Parent.cntName 

.txtKnownAs.Value’. 

Figure 2. Object hierarchy diagram. 

Andy: Correct. Of course, you can 

also take a shortcut, since you can see 

from the object hierarchy that you 

have to get all the way up to the form 

before you can start downwards 

again toward your objective. So 

you can simply start directly 

from the form using “ThisForm”, 

which would give you the 

address ‘ThisForm.cntName 

.txtKnownAs.Value’. Figure 3. Improved object hierarchy diagram. 

Paul: There’s one thing your diagram doesn’t make 

clear—why can’t I go directly from cntFormMode to 

cntName without passing through the form? There’s a line 

between them, isn’t there? 

Andy: No, there isn’t. Remember, we’re dealing with a 

hierarchy, so you can only go up or down. In reality, 

there’s no direct connection between the two containers— 

it’s just drawn that way for simplicity. Each object in the 

top row is actually connected directly, and only, to the 

form. “All roads lead to Form” . Similarly, to get from 

one text box in a container to another in the same 

container, you must go up to the container level before 

starting back down again. I suppose a more correct 

representation of the situation would look like Figure 3 

(I’ve added a few other objects so that you can see 

how they fit). 

Paul: Yes, that’s quite clear now. I do things slightly 

differently. Because I don’t always work these things out 

in advance, what I often do is print out the form and then 



write on it. I keep printouts of the form anyway for 

documentation, so an extra one for my reference is no 

great effort. While I’m in the form designer, I just press 

PrtSc on the keyboard, Alt-Tab to paintbrush, and 

Ctrl-V to paste in the screenshot, then print it landscape. 

Then I get out the four colored pens and draw boxes 

around the containers, write in their names, and write the 

names of controls. Then I might even write in the names 

of methods too, because there are occasions when the 

interface design is done with the customer before the rest 

of the design is finalized. 

Andy: That’s a useful little technique; I’d better try 

that out. Doing it in the designer means that you’ll get 

the names of all but the very smallest objects as part 

of the printout, too—nice! (I’ve always done it using 

a proprietary screen capture tool with the form 

running; I think I forgot about the PrtSc key when I 

gave up DOS). 

Paul: So do you want to summarize this whole business 

neatly now? 

Andy: I think so; let’s see. When Wendy Darling asked 

Peter Pan how to get to Never-Never Land, he drew her a 

mental map and used names that meant something to her. 

We need to follow the same approach when working with 

forms and containers. Name the objects meaningfully, 

and use some sort of visualization of the entire object 

hierarchy to ensure that we address objects properly. 

Doesn’t seem too difficult, really, does it? 

Paul: Nope, not difficult at all. One small difference, 

though—in FoxPro, if you don’t have a map, your 

program ends up in Never-Never Land. While you’re 

there, if you see a bag of marbles about, they’re mine! 

(clap, clap, clap, clap, clap, I do believe in FoxPro!) ▲ 

Paul Maskens is a VFP specialist and FoxPro MVP who works as 

systems engineer for AZURE IT Ltd., based in Oxford, England. 

pmaskens@compuserve.com. 

Andy Kramek is an old FoxPro developer and FoxPro MVP who 

works as an independent contractor based in Birmingham, England. 

andykr@solihull.bytenet.co.uk. 

Downloads December Subscriber Downloads 

• 12COASC2.ZIP—Source code described in Andrew Coates’s 

article, “Un-Mapping Mapped Network Drives.” 

• 12DONNSC.ZIP—Source code described in Jefferey 

Donnici’s article, “Seeing Patterns: The Mediator.” 

• 12DHENSC.ZIP—Source code described in Doug Hennig’s 

article, “Mining for Gold in the FFC.” 

• 12PETERS.ZIP—Source code described in John Petersen’s 

article, “Integrating ADO and Visual Basic into Your VFP 

Applications, Part 2.” 

Extended Articles 

• 12SETTI.HTM—Stephen Settimi’s article, “Creating a Set of 

Business Rules and the Making of a BusinessRule Server.” In 

this article, Stephen first shows how to visualize a business 

object as a collection of smaller objects. Once the objects 

are clearly identified and defined (the latter isn’t covered in 

Earn Money! 

. . . and see your name in print 

this article), it’s time to set out those business objects that 

might need rules, define those rules, collect them, and then 

execute them through a BusinessRule Server and maintain 

them as discrete object components. 

• 12SETTI.ZIP—Source code described in Stephen Settimi’s 

article, “Creating a Set of Business Rules and the Making of a 

BusinessRule Server.” 

• 12BOOTH.HTM—Jim Booth’s article, “What’s Really Inside: 

To Open the Tables or Not to Open the Tables—That is 

the Question.” Have you ever wondered if there’s any benefit 

to opening the tables for a SQL SELECT command before 

you execute the SELECT? Does the SELECT use the source 

tables that are already open? Interesting questions. Here 

are the answers. 

• 12BERG.HTM—“To PrintScreen or Not to PrintScreen.” Art 

Bergquist’s follow-up to his September article, “The Visual 

FoxPro Screen Image Printer.” 

Go ahead, add a line to your résumé—“Published Articles.” 

If your tip shows up in the pages of FoxTalk, 

we’ll send you $25. See the back page for the 

address where you can send your tips. 


23

Online Subscription Options Available! 

Electronic Access Package 

Move closer to your dream of the paperless office by 

subscribing to our electronic access package. This option 

includes unlimited online access to each monthly issue of 

the newsletter (including Subscriber Downloads) for the 

term of your subscription as well as the entire FoxTalk 

archive (1996-present). The search capability helps you find 

answers fast. To subscribe, go to www.pinpub.com/foxtalk/ 

subscrib.htm or call 1-800-788-1900 to speak to a customer 

service representative. 

Deluxe Package 

This option includes regular delivery of your print copies of 

the newsletter as well as online access to both the newsletter 

and Subscriber Downloads content. You’ll be able to access 

each monthly issue on the Web before it even hits the mail as 

FoxTalk Subscription Information: 

1-800-788-1900 or http://www.pinpub.com 

Subscription rates: 

United States: One year (12 issues): $179; two years (24 issues): $259 

Canada:* One year: $194; two years: $289 

Other:* One year: $199; two years: $299 

Single issue rate: $17.50 ($20 in Canada; $22.50 outside North America)* 

European newsletter orders: 

Tomalin Associates, Unit 22, The Bardfield Centre, 

Braintree Road, Great Bardfield, 

Essex CM7 4SL, United Kingdom. 

Phone: +44 1371 811299. Fax: +44 1371 811283. 

E-mail: 100126.1003@compuserve.com. 

* Funds must be in U.S. currency. 

Australian newsletter orders: 

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 

Internet: http://www.ashpoint.com.au 

The Subscriber Downloads portion of the FoxTalk Web site is available to paid 

subscribers only. To access the files, go to www.pinpub.com/foxtalk, click on 

“Subscriber Downloads,” select the file(s) you want from this issue, and enter the 

user name and password at right when prompted. 

well as obtain unlimited access to the entire FoxTalk archive 

(1996-present). The search engine makes looking for 

information on any topic a breeze. To subscribe, go 

to www.pinpub.com/foxtalk/subscrib.htm or call 

1-800-788-1900. 

Developer Solutions–Online 

If you haven’t already done so, go to www.pinpub.com 

and click on Developer Solutions–Online to check out the 

FoxTalk index of articles for free. (Tell your colleagues!) 

You can browse the entire index or enter a specific search 

term to pinpoint all of the related articles. If you don’t 

already have the material you need on hand, you may 

purchase individual articles (including the Subscriber 

Download file, if applicable) for $5 each online immediately. 

Visual FoxPro tips are free! No subscription required. 

Help us compile valuable salary information for you by participating in Pinnacle Publishing’s anonymous, online salary survey. 

Simply go to http://www.pinpub.com/foxtalk/FTsalfrm.htm (you don’t need to be a subscriber) and 

take two or three minutes to complete the survey. Watch for the results soon! 

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. 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 

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 

Direct all editorial, advertising, or subscriptionrelated 

questions to Pinnacle Publishing, Inc.: 

1-800-788-1900 or 770-565-1763 

Fax: 770-565-8232 

Pinnacle Publishing, Inc. 

PO Box 72255 

Marietta, GA 30007-2255 

E-mail: foxtalk@pinpub.com 

Pinnacle Web Site: http://www.pinpub.com 

FoxPro technical support: 

Call Microsoft at 206-635-7191 (Windows) 

or 206-635-7192 (Macintosh) 

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. 

User ser name 

Passw assw asswor or ord 

yield 

zealot

Un-Mapping Mapped Network Drives Andrew Coates - dFPUG-Portal

Create successful ePaper yourself

Delete template?

Save as template?