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 (including 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 properties 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 navigates 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 additional 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 SCATTER 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 object” 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 submitted 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.

Jim McGoldrick, who recently rejoined LA Fox and wanted to start a Consultant/Marketing SIG, died on December 30, 1995. The January meeting on “Marketing and Client Relations” was dedicated to him.

Page 9