The LA Fox Developer Newsletter

VFP Hot Tips...

From TakeNote Computer Consulting

Returning a Value from a Form

A common question we get asked in our VFP training classes

is “How do I return a value from a form?” It’s really pretty simple.

All you need to do is place

RETURN(THIS.ValueToReturn)

in the UnLoad Event of the form. You need to keep a couple

things in mind though.

I .You can’t return the Value property of an object on the form

because the Destroy Event for all form objects has already

occured. Instead, place the value to be returned in a form

property. That way it’ll be in scope when it’s needed.

2.The form’s WindowType property needs to be set to 1-Modal.

Now that we’ve got the form built, we need to know how to call

it. Call the form with:

DO FORM ABC TO xyz

where ABC is the form name and xyz is where the value will be

stored. Tha value can be a memory variable or property.

Field Caption Gotcha!

When working with the Table Designer to set field Caption

properties, watch out for this little trip-up. If you click on the

Expression Builder button to the right of the Caption text box

and type a caption *without* quotes, VFP will not consider that

a valid expression. If you put it in quotes, he will. The only

problem there is that your caption is in quotes everywhere in

your app.

Work around: Just type the field captions in and don’t bring up

the Expression Builder. When you type them directly in to the

Table Designer, they do not require quotes.

The SetAll Method

Do you find yourself setting the same property for multiple items

at a time? For example, you decide you want the font for all the

header captions in a grid to all be 12 point Anal with a blue

background and yellow text. Now you could manually set the

Font and FontSize properties in the Form Designer or you could

place these 3 lines in the Init event of the grid to have all of

those font settings set a runtime.

TH!S.SETALL(”FontName”,”AriaI”,”Header”)

THIS.SETALL(”BackColor”,RGB(O,O,255),”Header’)

THIS.SETALL(”ForeColor”,RGB(255,255,O),”Header”)

(Con’t, page 12)

December 1998

Integers and Other

Strange Animals

At one time or another we all run into the problem of how to

uniquely identify records in a table. We all have our favorite

schemas for accomplishing this. But in the final analysis using

the integer field type for key fields is more often than not the

best solution. In this document I will talk about the integer field

type and why integers make great keys and indexes and

relational database terms as they relate to keys,.

Integers - Not Like in Elementary School

Why is there an integer field type? I mean, an integer is just

another numeric with nothing following the decimal point. Isn’t

it?

In a word, no.

The data type name “integer” gives the false impression that it

holds the kind of information that we learned about oh so many

years ago. The integer data type actually holds a base 256

value! This means that using only four characters you can store

a integer values from -2GB+1 TO 2GB-I. That’s more than four

billion unique values can be stored in a four-byte field. A two-

byte field -32K+1 to 32K-I. A one-byte field -127 to +127

including zero. It rapidly becomes clear that using the integer

data type for indexing and primary keys is very attractive. In

one very compact field you can have one heck of a lot of unique

values.

In addition, indexing on the integer field is much faster than

indexing on character expressions. Numeric comparisons are

faster and easier for FoxPro to perform than character compari-

sons.

Also the size of the index file is much smaller than indexing on

a character field capable of holding the same number of unique

values. You will also find that SEEKs and joins are also

performs significantly faster.

Relational Database Terminology

In this discussion we will be looking the definitions of some

relational database terminology in the context of FoxPro. In

most ways these terms are have the same meaning as the pure

RDBMS model. But there are some differences.

Key - A

value, either simple or compound/concatenated, in each

record of a table that can be used to identify a record.

Simple

key - A key that consist of the data contained in a

single field in a table.

Compound/Concatenated key - A key made up of two or

more fields in a record to establish uniqueness.

Surrogate Key - A Simple key used to uniquely identify one-

and-only-one record in that table. This value has no

(Con’t, page 11)

Page 10