>Hello George,
>
>Thanks for explaining exactly what occurs during a foundation read. I'd like to go over a couple of things in your response.
>
>"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."
>
>The fact that they don't participate seems to be part of why I'm unable to achieve the results I want. But the browse windows themselves work as intended.
>
>"As has been documented, the foundation read executes any time the value of the WONTOP() function changes."
>
>So this means that the reason the foundation read is not executing is because once the user is in the browse window (which doesn't participate) and doesn't move back to the screen involved with the read, then there is no change in the the WONTOP() function?

No, the value of WONTOP() will change if you use the necessary syntax (clause, in this case) in the browse command. That syntax is BROWSE...WINDOW < window name >. If you don't specify a window, BROWSE will use the active window, and, yes, the foundation read won't execute. IOW, the program that creates the browse, must first use DEFINE WINDOW to define the window, then issue the BROWSE...SAVE WINDOW < window name >.

>"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."
>
>When moving to the browse window we don't want to clear the read. The screen displays the current record selected in the browse window. What I was trying to do was to add code that would return the user from the browse window back to the screen/window involved with the read. After returning there, if I issue a clear read, shouldn't it execute? I haven't been able to get it to do so. Once I leave the screen, go to the browse window, and select a menu option, even if I include code that tells the program to activate the screen involved with the read, it still hangs at this point.

This is why you need to track the window names and associated programs (spr files). When the new window is brought to the top, if the window isn't found in the list, then do nothing. If it is, you execute the spr file.

Another function you need to be aware of is WREAD(), it tells you whether or not the current window is participating in the read. You don't need to issue a read (or clear it) because the original one should still be in effect. When you start a new program (screen), that's the time to check the RDLEVEL(), and, if greater than 1, clear the read.

>"Does this help?"

>Yes, it helped.

I'm glad, 'cause I wasn't so sure. In my mind, trying to explain the ins and outs of the foundation read is a lot more difficult than trying to understand event driven programming.

If you have more questions