M
Matt Gilarde
Guest
RWEBSTER The issue I see with both solutions is that the now 'alive but busy' window can't regain focus once it's lost, and so becomes 'trapped' behind other windows until the window finishes up. Is there anything that can be done here? I guess it may mean processing *some* of the messages, but not others? Thoughts? You may be able to keep the busy window from becoming completely inactive by handling messages like WM_NCACTIVATE and the other WM_NC* messages. This is basically what SESSION:MULTITASKING-INTERVAL does. You can run the following code to see the difference. If you set MULTITASKING-INTERVAL to 0, you won't be able to bring the window to the foreground if you activate another application. If you set MULTITASKING-INTERVAL to 100 you will be able to bring the window to the foreground even though it's busy running the loop. /* Set MULTITASKING-INTERVAL to a positive non-zero value to make ** the window respond to activation messages while it's busy. Set ** it to 0 to make the window not respond to activation messages. */ SESSION:MULTITASKING-INTERVAL = 100. DEFINE VARIABLE i AS INTEGER. DO i = 1 TO 1000000: DISPLAY i. END. MULTITASKING-INTERVAL uses PeekMessage to check the message queue but, unlike the PeekMessage code I posted earlier, it actually removes some messages and handles them. MULTITASKING-INTERVAL is sort of a lighter weight, automatic version of PROCESS EVENTS. I realize that the more I say the more confusing this is probably becoming. I'm planning to create a page on the wiki to go into this subject in more depth. Each of the methods I've talked about (PROCESS EVENTS, MULTITASKING-INTERVAL, and PeekMessage) has its place and this topic deserves a fuller treatment than I have given in this piecemeal fashion.
Continue reading...
Continue reading...