PRB: Calling Screen from Another Without Jumping a READ Level (104054)
The information in this article applies to:
- Microsoft Visual FoxPro for Windows 3.0
- Microsoft FoxPro for Windows 2.6
- Microsoft FoxPro for Windows 2.6a
- Microsoft FoxPro for MS-DOS 2.6
- Microsoft FoxPro for MS-DOS 2.6a
- Microsoft FoxPro for Macintosh 2.6a
This article was previously published under Q104054 SYMPTOMS
Many FoxPro programmers want to be able to execute one screen from another.
This may present problems if the READ command from the calling screen is
not cleared before the next screen is executed and more than five screens
are executed. The most common error message encountered is "Too many READs
in effect," which is the result of having more than five READS in effect,
which is a FoxPro limit.
CAUSE
The most common, though incorrect, way to try to solve this problem is to
enter something similar to the following code in the VALID clause of a push
button on Screen1:
CLEAR READ
DO screen2.spr
Looking at this code, it appears that the READ command will be cleared and
that Screen2 will then be executed. Actually, the READ command from Screen1
stays in effect, Screen2 is executed, and the Screen1 READ command is not
cleared until the READ command from Screen2 is cleared and control is
returned to Screen1.
This behavior occurs because in order for the CLEAR READ command to be
recognized by the current READ command, program control has to be returned
to that READ command. In this example, the CLEAR READ command is issued and
then program control is immediately transferred to SCREEN2.SPR; the READ
command for Screen1 never has a chance to act on the CLEAR READ command and
therefore Screen1's READ command is not cleared before the DO command for
SCREEN2.SPR is issued.
RESOLUTION
***************************************************************************
IMPORTANT: This technique is not intended to replace a foundation READ, but
is a way to get around the limitation of not being able to have more than
five READs in effect at one time. Because a DO command is being executed
from another DO command, there is a form of recursion occurring and the
error "DO nesting too deep" will appear if the limit of 32 DO levels is
reached.
***************************************************************************
To achieve the desired behavior, issue the CLEAR READ command as done
above, but don't issue the DO screen2.spr command until after the READ
command has been cleared. For example:
- In the Screen Builder, create a new screen.
NOTE: In FoxPro for MS-DOS, choose Screen Layout from the Screen menu,
and change the screen type from Desktop to Window.
- Create a push button with two prompts: <Screen2> and <Quit>. Make the
variable "m.choice". Open the Valid code snippet and add this code:
IF m.choice=1
tobedone="screen2.spr"
ENDIF
CLEAR READ
If the Screen2 button is chosen, TOBEDONE is set to the name of the
proper program file. The CLEAR READ command is issued if either button
is chosen. Control is returned to the READ command and it is CLEARed.
- Open the Setup code snippet and add this line of code:
tobedone=space(12)
This variable stores the next screen to be executed.
- Open the Cleanup code snippet and add these lines of code:
IF EMPTY(PROGRAM(30)) && Check if we are about to exceed the
IF NOT EMPTY(tobedone) && 32-level DO limit. If we are, the next
DO (tobedone) && program isn't executed and an error
* message appears.
ENDIF
ELSE
WAIT WINDOW "32 DO Level Limit exceeded"
ENDIF
This code tests whether TOBEDONE has been assigned a value that means
the Screen2 button was chosen. If Screen2 was chosen, the value in
TOBEDONE is executed using a name expression. If the screen is exited in
some other fashion, that is, the ESC key or the Quit button was chosen,
nothing is executed.
NOTE: Make sure this is the last line in the Cleanup code.
This code example never leaves the originating program, so all variables
declared in each screen set will remain defined until you quit the original
calling screen. The program will have to manually release the memory
variables in the Cleanup code.
Modification Type: | Major | Last Reviewed: | 12/3/2003 |
---|
Keywords: | kbcode kberrmsg KB104054 kbAudDeveloper |
---|
|