The LA Fox Developer Newsletter

February 1996

The VFP SCATTER NAME Command

By Steve Sawyer

(Ed. Note: Reprinted with permission from the DetroitArea FoxPro

Developer’s Group.]

It's amazing that you can work with Visual FoxPro for many months

and still come across some Really Cool Stuff that you had no idea

even existed. With the advent of data buffering, many folks (in-

cluding me) have made comments to the effect that we may never

use SCATTER and GATHER again. Well, not so fast, bucko!

There is a new clause for the SCATTER and GATHER commands

that is almost too impressive for words: the NAME clause.

Open a table, and issue the following in the command window:

SCATTER NAME oRecord

DISPLAY OBJECTS

Whaddya got? An object called oRecord, that has a set of proper-

ties that correspond to each of the table’s fields, and to which the

field values have been SCATTERed! GATHER NAME oRecord will

reverse the process.

Ok, Steve, that’s slick, but what can we do with it? Well, since a

property of an object (like a form) can be another object, imagine

having a form object with a property called oRecord, with this code

in its InitO:

SCATTER NAME ThisForm.oRecord

Or, imagine having a form with an array property called aRecords,

and a numeric property called nEdited. Each time the user navi-

gates to a record and begins to edit that record, the following code

executes

ThisForm.nEdited = ThisForm.nEdlted+ I

DIMENSION ThisForm.aRecords[nEdited]

SCATTER NAME ThisForm.aRecords[nEdited]

So what you have is an array of objects as a form property that

would allow the user not only to “cancel” the current edit, they

could roll back any or all of the previous edits in that session!

Many folks have complained that you can easily pass an array by

reference as an argument to a FoxPro 2.x screen, but this isn’t

practical with a VFP form, because any parameter received by

the form is scoped to the lnit() method, and goes out of scope

when the Init()'s execution ends. You have to take some addi-

tional steps, such as copying the passed array’s contents to a

form array property, but then you’re faced with the problem of

passing the array back to the calling program etc. Some have

suggested creation of an “array object” that could be easily passed

(objects can only be passed by reference) to other objects.

This brings us to a way to work around the limitation of the SCAT-

TER NAME syntax; you cannot scatter memo fields using SCAT-

TER NAME. However, as you know, you can SCATTER TC

<arrayname> MEMO to accomplish this. So, just take the twc

ideas, SCATTER TO ... MEMO and the creation of an array ob-

ject” and you come up with this:

USE ctablenam.>

oArray - CREATEOBJECT(”cArray”)

SCATTER TO oArray.aArrayProperty

SUSPEND

DEFINE CLASS cArray AS custom

DIMENSION aArrayProprty[1]

Hope these “teasers” lead to some interesting ideas of your

own.

Find out about how to get on

the LA Fox-Cast list at the next

meeting!

It Can’t Get Any Easier......

We’ve come up with an easy way to submit articles to

the LA Fox Developer Newsletter one that has been

overlooked for a long time.

You can submit your articles to Barry Lee at CIS#

72723,3422 on Compuserve.

These articles can be on any FoxPro-related topic,

whether it concerns a new technique you’ve discovered,

a certain development technique you may favor over

others, book reviews, etc. Editor reserves the right to

edit or offer constructive comments concerning submit-

ted articles and accepted articles shall be considered to

be in the public domain.

The quality of this newsletter really depends on the

members that support it, not just read it. And I think we’d

all be surprised by the useful information that could be

circulated around the membership.

So.

How 'bout it?

Jim McGoldrick, who recently rejoined LA Fox and

wanted to start a Consultant/Marketing SIG, died on

December 30, 1995. The January meeting on “Mar-

keting and Client Relations” was dedicated to him.

Page 9