PRB: Cursor Skips GET Object(s) on New Record

• Microsoft FoxPro for Windows, version 2.6a
• Microsoft FoxPro for Macintosh, version 2.6a
• Microsoft FoxPro for MS-DOS, version 2.6a

SYMPTOMS

The following occurs when you enter data for a new record as you use a window that has GET objects for character variables:

1. The cursor skips past the GET objects.

2. The cursor won't move back to the GET objects when you press SHIFT+TAB.

3. The cursor skips the GET objects again when you press TAB enough times to cycle through all the objects on the screen and return to the skipped GET objects.

4. FoxPro processes the WHEN and VALID clause code of the skipped objects.

CAUSE

This behavior occurs when all the the following conditions are true:

• The GET object displays a memory variable.
• The GET size is smaller than the field in the record or smaller than the memory variable that originally initialized the data in the GET object,
• The memory variable for the field or other memory variable was set to null ("") when you established that the next transaction was a new record or took some other action to re-initialize the GET object(s).

• Design reasons - for example, to place more GET objects on a single line.
• The font is so large that the data in the GET must be scrolled to the right and left to be seen.

WORKAROUND

1. Re-initialize the memory variables with this command:

   SCATTER MEMVAR BLANK

2. Use a format Function/Picture mask to control the number of characters in the GET. Here's an example of a Format mask for a 15-character "Last Name" GET:

   AAAAAAAAAAAAAAA

STATUS

This behavior is by design. FoxPro sees the smaller GET object (one that has a SIZE smaller than the maximum field or variable size) as one that requires scrolling of the input data, as the variable is larger than the space for data.

Accordingly, FoxPro re-measures the variable each time rather than accepting its size at the first occurrence of the variable. Because the variable was set to null subsequent to the first occurrence, FoxPro sees it as having no dimension and skips over GET objects that use the variable.

When the GET object's size is defined as matching the size of the variable, or as larger than the size of the variable on the first occurrence of the variable, FoxPro does not resize the definition of the variable thereafter.

MORE INFORMATION

Steps to Reproduce Behavior

1. Create and execute the following program:

   *: TEST PROGRAM - Entitled TEST1.PRG ***************************** SET TALK OFF CREATE TABLE x (field1 c(10), field2 c(10)) APPEND BLANK REPLACE field1 WITH "xxxxxxxxxx" REPLACE field2 WITH "yyyyyyyyyy" SCATTER MEMVAR @ 1,1 SAY ;

         "Tab through the objects on this screen and watch the WAIT WINDOWS,"
   

   @ 2,1 SAY "Click the New Record button, and tab again" @ 4,1 SAY "Field1: " GET m.field1 SIZE 1,9 WHEN show1() VALID show2() @ 5,1 SAY "Field2: " GET m.field2 SIZE 1,9 WHEN show3() VALID show4() @ 6,1 SAY "Field1 again: " GET m.field1 SIZE 1,11 test = 1 test2 = 1 @ 8,1 GET test PICTURE "@*N New Record" VALID new_rec() @ 9,1 GET test2 PICTURE "@* Exit" READ CYCLE CLEAR USE DELETE FILE x.dbf

   *: **** PROCEDURES ****

   PROCEDURE new_rec m.field1='' m.field2='' SHOW GETS _CUROBJ=1 RETURN

   PROCEDURE show1 IF m.field1 == ''

        WAIT WINDOW "Field1's WHEN " TIMEOUT .8
   

   ENDIF

   PROCEDURE show2 IF m.field1 == ''

        WAIT WINDOW "Field1's VALID" TIMEOUT .8
   

   ENDIF

   PROCEDURE show3 WAIT WINDOW "Field2's WHEN " TIMEOUT .8

   PROCEDURE show4 WAIT WINDOW "Field2's VALID " TIMEOUT .8

   *: End of Test1.prg *************************************

2. Click the "New Record" button. The cursor moves to the GET labelled "Field1 again: " and cannot be made to return to the GET labelled "Field1: " until an entry is made in the "Field1 again: " GET's edit region.

3. Make an entry in the "Field1 again: " GET's edit region. Then m.field1 contains a non-null value that will be displayed in the "Field1: " edit region by the "Show Gets."

   M.field2 is still set to null, so the GET for "Field2: " will be skipped. Notice that even though a GET edit region is skipped, the WHEN and the VALID for that GET object are still activated.