This is not, normally, a problem if you follow the simple loop structure as set out in that comment. BUT, what happens if you have an error in your SBasic program which is produced just after a return from the PWactivate call as a result of a hit/do routine? Then the program is interrupted, you will edit it , and run it again - leading to the loss of memory and possible confusion mentioned above.
If this happens (i.e. the program stops with an error), the first thing to do is to use the PWquit keyword. This unravels all of these complications and makes a clean exit again to SBasic. You can then edit the error and run the program again. Of course, you do not -and indeed MUST not- use this when no ProWesS window was still on the screen when the error happended, since then you are no longer in ProWesS.
PWquit
The object and mempointer variables are those that were used in the PWactivate call. Now you can understand why you should not make these variables LOCal, since after an error, the local variables are sometimes no longer accessible....
ATTENTION: if you use wrong parameters for this command (i.e variables that aren't those needed, such as a wrong mempointer), you will:
PWquit
Since my programs often crash during development (only!), I generally include the following procedure in my programs:
DEF PROC unset (o,m) PWquit o,m PWremove o END DEF unsetwhich makes a clean exit with PWquit, and also removes the object with PWremove.