>Hello George,
>
>Thanks for responding. I have this posted on the Microsoft board also, so I'll try to explain what I've done & what I'm trying to accomplish.
>
>In the main program I have a foundation read with a valid clause. My menu is launched from the main program. From the menu bar the enduser can select one of four screens which also have browse windows. The menu options execute a routine (in the menu cleanup code) which contains an IF-THEN structure which checks the read level. If it is NOT > 1, then the only read that is active is the Foundation READ and the screen program (.spr) the user selected from the menu is run. If it is > 1, that means that the user already has a screen open and is attempting to open a new screen. Before this can happen, the first screen & browse window need to be closed so that the nested reads don't accumulate and exceed the maximum number. The screen & browse windows are closed and a CLEAR READ is issued which returns the program to the VALID clause in the Foundation READ along with the name of the screen the user selected, as a parameter. The VALID clause tests to see if the user has indicated he is
>exiting the application. If not, the program then runs the screen name it received.
>
>The problem occurs if the user leaves the screen and begins working in the browse window. From what I've gathered (and what has been explained to me) - because the browse window doesn't have or involve any "@ get" commands, then issuing a CLEAR READ has no effect on it. So instead of returning to the VALID clause of the Foundation READ, it just stays in a wait state.
>
>I've tried adding code that re-activates the screen that in involved with the original READ issued by the screen code, but according to the debug window, FoxPro still doesn't recognize the screen as being the last/output/wread window.
>
>The only workaround that I could come up with is to disable the menu whenever the user leaves the screen to go to the browse window. With no other options, they are then forced to return to the screen and click on the EXIT button which has Terminate Read on Selection check marked.
>
>What I'd ideally like is some way for them to be able to use the menu options even if they're in the browse window. If anyone knows of a way to do this I'd be eternally grateful. Thanks.

First, browse windows do not participate in foundation reads. As I mentioned previously, however, in order to keep them active within a program you need the SAVE clause in the BROWSE command.

It would seem as if it might be helpful to explain exactly what happens with the foundation read. As has been documented, the foundation read executes any time the value of the WONTOP() function changes.

In general, the strategy used is to check RDLEVEL() prior to executing the call to a new screen. If it's greater than 1, then clear the read. This causes any code existing after the screen's READ clause to execute. If code exists there to release the window, it gets executed. The strategy here was to conditionally release the window based on the value of a logical variable. IOW, if the user indicated that the window was to be closed, it was released, otherwise it wasn't.

I used an array that contained the window names and the names of the spr files that created them. If the foundation read fired as a result of a new window being brought to the front, what occurred was that the array was scaned for the new value of WONTOP() and when found, the spr was called accordingly. This meant that any setup code was re-executed.

The code has to be designed with these factors in mind. When you bring up your browse window, the deactivate event fires. Here you have to determine whether or not to clear the read. By choosing not to do so, the current read stays in effect and the browse window is activated. Since the read is still in effect, when you return to the screen it acts as if nothing has changed.

Does this help?