Specifications

Apple IIGS
#75: BeginUpdate Anomaly 1 of 4
Apple II
Technical Notes
Developer Technical Support

®
Apple IIGS
#75: BeginUpdate Anomaly
Revised by: Dave Lyons May 1992
Written by: Eric Soldan January 1990
This Technical Note discusses a Window Manager anomaly with the handling of the visRgn and
the updateRgn between BeginUpdate and EndUpdate calls.
Changes since January 1990: Updated for System 6.0. CopyPixels is in a static segment,
and GS/OS automatically prompts for disks on the text screen when necessary to avoid interfering
with a window update in progress.
If an application calls BeginUpdate, it needs to be fully aware of what is going on behind the
scenes in terms of its visRgn and updateRgn. Typically an application has TaskMaster
handle the update events. TaskMaster calls BeginUpdate, the application update procedure,
then EndUpdate. So any application that uses TaskMaster to handle updates, whether or not it
makes any BeginUpdate calls directly, needs to be aware of problem described in this Note.
BeginUpdate is responsible for intersecting the visRgn and the updateRgn and making the
intersection of these two regions the temporary visRgn. (EndUpdate undoes this effect.)
Following are the steps BeginUpdate takes to do this:
1. Localize the updateRgn. (All grafPort regions are local, therefore the
visRgn is local. All window regions are global, therefore the updateRgn is
global. One of them has to change if they are to be intersected correctly.)
2. Intersect the visRgn and localized updateRgn, then place the result in the
updateRgn.
3. Swap the visRgn and updateRgn handles.
The handle swapping has two effects:
• Makes the intersection region the current visRgn.
• Saves the real visRgn as the updateRgn. (Saving the real visRgn is
necessary because everything has to be restored to normal by EndUpdate.)
EndUpdate restores things to normal after an update procedure is finished. When an application
calls EndUpdate, it swaps back the handles and sets the updateRgn to empty.