FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

WINDOWS

Update a window holding a picture


I believe what happens is something like this:

The Window Manager (?) keeps track of which windows cover up what parts of which other windows. Every window's data includes a structure called the window's "invalid region," which roughly speaking, is a geometrical description of which parts of the window have been covered up (and then uncovered again) since the window was last refreshed. Every time a part of the window becomes newly uncovered, the Window Manager adds that new chunk to the window's "invalid region" description.

If a window's invalid region is not nil--that is, if there really is some region of the window that's been declared "invalid"--then the system puts a "window refresh event" (a request to refresh the window) onto the event queue.

One of the (many) things that HANDLEEVENTS does is read the event queue. If it discovers a "window refresh" event there, then it will call your specified "DoDialog" function to handle it. BUT...HANDLEEVENTS first _erases_ the window's invalid region (i.e., paints it with the background pattern, usually flat white) just _before_ it calls your FN DoDialog. I'm sure that Staz & Andy were just trying to be helpful here, and assumed they were saving us a step in the redrawing process. But the result is, if you try to refresh the window _after_ it gets uncovered but _before_ HANDLEEVENTS is called, your redrawing gets wiped out. To recap the sequence:

1. Window gets covered up by dialog.
2. Window gets uncovered. And in response:
2a. Window Manager declares newly-revealed region "invalid";
2b. System posts a "window refresh" event in the event queue.
3. Unwary programmer draws a picture in the newly-uncovered window.
4. Program calls HANDLEEVENTS, which does this:
4a. Sees the "window refresh" event;
4b. Paints over the window's invalid region;
4c. Sets the window's invalid region to nil;
4d. Calls your FN DoDialog.

So, step 4b undoes step 3.

This is why we're always advised to put all of our window-refreshing logic inside FN DoDialog (or in another FN called by FN DoDialog). It's because any drawing we do elsewhere stands a chance of getting wiped out in Step 4b.

Rick