info-mac@uw-beaver.UUCP (07/21/84)
From: INTMET@BBNA.ARPA It seems that the window manager does not generate an update event for the desk top. Since the desk top isn't realy a window it isn't clear how it would refer to it. A comment in the work shop pascal sources that were included in sumacc annotates a check if the update is on a window who's pointer is null says "Whats this for?" And the awnser seems to be... if it was ever decided to generate update events for the desk top then it might be reffered to by using a null pointer in the event message. I presume that finder updates its "desk top" by slipping a real window over the entire desk, sort of a table cloth I guess. The manual suggests that if you recieve an update event for a desk accessory that you ignore it, it also says that it should neve happen. It realy isn't a good idea ever to ignore an update event, the event manager checks for windows which need updating often, if you don't call BeginUpdate and EndUpdate on the window once you get the update event then the event manager will keep throwing the event at you with a passion. Ben Hyde -------
info-mac@uw-beaver (info-mac) (10/26/84)
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA> Ah yes, that IS a real gotcha. It's also worth keeping in mind the same holds true for activate events as well, you MUST set the port before drawing anything. The place where I found this out the hard way was when my code closed a desk accessory and forgot to reset the port when the activate event occured for my window. It would use the old accessory's (now disposed) port, and the window manager would try and clip the drawing to the disposed port's region. This sent quickdraw into never-never land because the disposed region was now garbage... -------
info-mac@uw-beaver (info-mac) (11/02/84)
From: Robert.White@CMU-CS-GANDALF
For those who have not yet discovered this "feature". I will explain in
Pascal, but the same is true if you are using the SumMacC stuff. If you
have multiple windows and you are processing an UpdateEVT you normally
would have code like this:
beginupdate (ThePTR);
{update code}
endupdate (ThePTR);
Unfortunately, some updates (like TEUpdate) get updated through the
current port, and not "ThePTR". You would think that "beginupdate"
and "endupdate" would take care of retaining port references. It
does not. You would think that TEUpdate would use the "InPort" field,
it does not. You should write your code like this:
getport (WasPort);
setport (ThePTR);
beginupdate (ThePTR);
{update code, including TEUpdate if needed}
endupdate (ThePTR);
setport (WasPort);
I hope this helps you. I have told the Mac Support People at Apple and
they thanked me and said they would pass the information to the document
people. I guess this means they will treat it as a feature and make
the documentation clear as to what happens instead of also making the
fixes in new ROM generations.
Robert White
rjw@cmu-cs-gandalf.arpa