PRB: SAY Field Refresh Option Causes Hidden Window to Reappear

2.50b     | 2.00 2.50 2.50a 2.50b | 2.50 2.50a 2.50b
MACINTOSH | MS-DOS                | WINDOWS

The information in this article applies to:

• Microsoft FoxPro for Macintosh, version 2.5b
• Microsoft FoxPro for MS-DOS, versions 2.0, 2.5, 2.5a, and 2.5b
• Microsoft FoxPro for Windows, versions 2.5, 2.5a, and 2.5b

SYMPTOMS

When you are running a screen set with multiple windows in which one has been hidden, the hidden window reappears even when a SHOW WINDOW command has not been executed.

CAUSE

In addition to other screen objects, the hidden window contains at least one SAY/output object, and the Refresh Output Field check box is selected. A SHOW GETS command that does not include a WINDOW clause is placed in a user-defined code snippet to update objects on the screen.

To understand why this behavior occurs requires looking at the generated screen code. When the FoxPro screen code generator (GENSCRN.PRG) creates the screen program (.SPR) from a screen with a SAY/output field, the Refresh property of which has been checked, it generates code in the SHOW snippet which looks like the following:

   IF SYS(2016) = "SCR1" OR SYS(2016) = "*"
      ACTIVATE WINDOW scr1 SAME
      @ 1.000,2.800 SAY company ;
         SIZE 1.000,80.800, 0.000 ;
         FONT "MS Sans Serif", 8
   ENDIF

The following command will update the objects on the current window only:

   SHOW GETS WINDOW (WOUTPUT())

RESOLUTION

See "Workarounds" in the "Steps to Reproduce Behavior" section below.

STATUS

This behavior is by design.

MORE INFORMATION

WARNING: ANY USE OF THE CODE PROVIDED IN THIS ARTICLE IS AT YOUR OWN RISK. Microsoft provides this code "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Steps to Reproduce Behavior

The following procedure illustrates the behavior described. The steps describe dialog boxes and objects found in FoxPro for Windows and FoxPro for Macintosh. Minor differences exist in the FoxPro for MS-DOS environment.

1. Open the CUSTOMER table (CUSTOMER.DBF) in the TUTORIAL subdirectory beneath the FoxPro main directory.

2. Create a screen, and save it as SCR1.SCX.

3. In SCR1, choose Screen Layout from the Screen menu and type "SCR1" (without the quotation marks) as the window name and "SCR 1" (without the quotation marks) as the window title.

4. Create an output field, select the Refresh Output Field check box, and specify the COMPANY field as the field to output.

5. Create a push button with the prompts "OK" and "NEXT SCREEN" and an "M.OK" variable. In the VALID code snippet, enter the following code:

   DO CASE

             CASE m.ok=1
                CLEAR READ
             CASE m.ok=2
                HIDE WINDOW scr1
                SHOW WINDOW scr2
                _CUROBJ=OBJNUM(m.choice)
           ENDCASE
   
   

6. Create a second screen, and save it as SCR2.SCX.

7. In SCR2, choose Screen Layout from the Screen menu and type "SCR2" (without the quotation marks) as the window name and "SCR 2" (without the quotation marks) as the window title.

8. Create an output field, select the Refresh Output Field check box, and specify the CONTACT field as the field to output.

9. Create a push button set with the prompts "OK" and "Update" and an "M.CHOICE" variable. In the VALID code snippet of the push button set, enter the following code:

   DO CASE

             CASE m.choice=1
                CLEAR READ
             CASE m.choice=2
                SKIP
                SHOW GETS && WINDOW (WONTOP())
          ENDCASE
   
   

10. In the ON SCREEN ENTRY (When) code snippet, enter the following line of code:

    HIDE WINDOW SCR2

11. Save both SCR1.SCX and SCR2.SCX, bring SCR1.SCX to the foreground, and generate the two screens together. SCR1 should be listed first in the screen set list box.

12. Run the screen program SCR1.SPR. Disregard the momentary appearance of SCR2. This is a side-effect of combining two independent screens together in a single READ and is discussed below. When SCR1 is waiting to receive input, choose the Next Screen push button. SCR1 disappears and SCR2 appears. Clicking Update causes SCR1 to reappear.

Workarounds

To correct the screen set created above, eliminate the comments (&&) in step 9, save SCR2.SCX, and regenerate the screen set, making sure that SCR1 is listed first in the screen set list box of the Generate Screen dialog box.

There are a variety of ways to combine a screen set. If the limit on the number of READs is a concern, see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q106697
   TITLE     : How to Prevent "Too Many READs in Effect" Error Message

If speed of execution between screens is a concern, SAY fields cannot be used. Instead, use GET objects. In the WHEN clause of each GET, return the value .F., so that the user cannot enter the field.

A fundamental problem exists with the method described for tying two independent screens together in a single READ, commonly referred to as a "screen set." Without modifying the .SPR directly, there is no way to avoid the momentary display of the hidden window before it is hidden again by the HIDE WINDOW command the user places in the ON SCREEN ENTRY code snippet. The screen generator doesn't provide an option to prevent the display of one or more windows combined in a screen set. While the flicker may be momentarily distracting on slower computers, the speed gained in having more than one screen in memory simultaneously may provide justification. Another benefit is that only a single READ level is consumed by all screens involved.