6
|
|
6 |
|
|
The LA Fox DeveloDer Newsletter
|
|
July
1997
|
|
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) 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’
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. However, 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 converted to the 3.0 format. This scenario does a nice job of
|
|
Page 6
|
|
|
6 |
|