The LA Fox DeveloDer Newsletter

July 1997

Hot Tips from FoxTalk

Set Focus to a Control When a Record is Added

by William O’Connor

To set focus to a particular control when a record is added, add

a new property to your form called cAddfield. Then add this

method and give it the name of your choice:

* This method requires the form to have a property

* called cAddField. cAddField MUST contain a fully

* specified object path pointing to the object.

* For example:

* cAddField = 'PageFrame1.Page1.txtEmployee'

Please note that this will set focus, but won’t change

the page to show the field if it is on the non-current

page of a pageframe.

IF TYPE("THISFORM.cAddfield") = “C” AND;

NOT EMPTY(THISFORM.cAddField

cObjName = ALLTRIM(ThisForm.cAddField

= EVALUATE(”THISFORM.” + ALLTRIM(cObjName)

+ “.SetFocusØ”)

ENDIF

If you named this method SetFocusOnAdd, you’d execute it just

after adding a record using a call like this:

THISFORM.SetFocusOnAdd()

Why not just call the SetFocus method for the specific object

directly? Because maintaining and subclassing the form is

easier this way, particularly if you need to perform this operation

from many places within your form, or even from outside the

form (say, in an object that manages database access or in a

stored procedure). In that latter situation, you could issue a

command like this:

SCREEN.ActiveForm.SetFocusOnAdd()

The SYS(3) Trap

by Paul Wasserman

The SYS(3) function returns an eight-character, allegedly unique

number that gives you a handy way to generate a unique file

name in FoxPro. Overuse can, however, be dangerous to your

applications. We bumped into this problem when we used 10

sys(3) calls in a row, as in the following:

tempfile1 = SYS(3)

tempfile2 = SYS(3)

tempfile3 = SYS(3)

To our dismay, we found that the faster the computer we ran on,

the more likely SYS(3) was to give us duplicate numbers. If you

want to try this for yourself, try the following little program,

preferably on a Pentium:

CLEAR

DIMENSION x(100)

FOR i = 1 TO 100

x(i)SYS(3)

ENDFOR

DISP MEMO LIKE x

Scan the results, and you’re sure to see some duplicates.

If you want to get your temporary file names this way, the safer

bet is to call SYS(3) just once, then create additional filenames

by incrementing the value. We’ve taken this one step further to

make our debugging easier. By controlling the last character of

the filename, we know which temp file we’re looking at, as in the

following:

tempseed = LEFT(SYS(3),7)

tempfile1 = tempseed+'1'

tempfile2 = tempseed+’2’

tempfile3 = tempseed+'3'

tempfile4 = tempseed+’4’

tempfile5 = tempseed+’5’

Exercise Caution with Remote Views that

Encompass FoxPro 2.x Tables

by John V Petersen

If you elect to use a remote view in Visual FoxPro to access

and update data in a 2.x table, make sure the key you select in

the View Designer is unique.

For example, assume the 2.x table has a column called ID,

dimensioned as C(5), and you select this as the key column in

the View Designer. Further, assume that two records have an ID

value of 00001. If you open the view via a USE command, delete

one of these records, and subsequently call TABLEUPDATEO,

you may be surprised by the results you get. Inspecting the 2.x

will yield that BOTH records were deleted.

Why? First, because this is what you told ODBC to do. In

effect, you said, “Delete every record in the back-end table with

this value ("00001"in this case) in the key column.” Since two

records have this value, two records were deleted. At first, you

may say to yourself, “But, they are two distinct records with

different record numbers. FoxPro should have known better.” In

fact, ODBC knows nothing about a record number. The FoxPro

ODBC driver most likely took your actions in the view and

converted it to a FoxPro command such as the following:

DELETE FOR ID = ‘00001’

Obviously, this whole issue would be eliminated if the FoxPro

2.x tables were accessed directly like in Visual FoxPro. How-

ever, if you need to have 2.x access as part of a database, a

view will be your only alternative since the 2.x table can’t be a

member of the database. If you were to include it, it would be

inaccessible by FoxPro 2.x since the header would be con-

verted to the 3.0 format. This scenario does a nice job of

(Con't, page 7)

Page 6