Xref: utzoo comp.sys.mac:21222 comp.sys.mac.programmer:2650
Path: utzoo!attcan!uunet!peregrine!zardoz!dhw68k!thecloud
From: thecloud@dhw68k.cts.com (Ken McLeod)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: Moire bug with MS Word 3.02
Summary: Moire WaitNextEvent bug splunge
Message-ID: <12606@dhw68k.cts.com>
Date: 5 Oct 88 12:11:36 GMT
References: <882@hub.ucsb.edu>
Reply-To: thecloud@dhw68k.cts.com (Ken McLeod)
Organization: Wolfskill residence; Anaheim, CA (USA)
Lines: 69

In article <882@hub.ucsb.edu> steveg@squid.ucsb.edu (Steve Greenland) writes:
>I've come across an interesting bug involving Moire 2.12 (recently
>posted to comp.binaries.mac) and MS Word 3.02.  If you are in the 
>"Page Preview" mode of Word and Moire is activated (either through
>timeout or by putting the mouse cursor in the upper right corner of
>the screen), when you try to go back to Word, the system will crash. 
>Any modifications since the last save will be lost.
>
>My system is a Mac II, System 6.00, 1 Meg of memory.  

 I have also had this occur, and I think it may actually be a problem with
WaitNextEvent being implemented in System 6.0x all the time.

 The de-activation of Moire was causing my program under development to
crash, so I tracked down the cause:

 Moire works by putting up its own window (the size of the screen) in
front of all others, then paints it black. When it deactivates, this
window goes away, and windows underneath it must be redrawn. Most Macintosh
applications now call WaitNextEvent if it is implemented, and upon
getting an event (in this case, an UpdateEvt), branch to an appropriate
function to deal with it. Generally, the message field of the event is
passed to a "doUpdate" function, which treats it as a pointer to the
window that needs updating.

 Normally, if a program is NOT running under MultiFinder, we can expect
that any UpdateEvt's given to us by GetNextEvent/WaitNextEvent are for
our application's windows only (read: windows our application is
responsible for drawing). Therefore, we SHOULD be able to assume that
the message field of the event is a valid WindowPtr to one of "our"
windows, and if GetNextEvent gives us the event, that's true. However,
when WaitNextEvent gives us the event in the non-MF System 6.0x world,
that isn't true anymore (I don't think).

 Anyway, one of the first things that a "doUpdate" function usually
does, upon receiving the pointer to a window to be updated, is call
the toolbox routine BeginUpdate(theWindowPtr). If "theWindowPtr" is
not valid, we die! Pow! Restart!

 It appears that somehow we are getting an "event" to update Moire's
window! But the window is gone, and the pointer is therefore invalid.
The solution (obviously) is to check the pointer's validity before
calling BeginUpdate() with something like this:
 if (!(theWindowPtr == myWindowPtr)) { /* we're in trouble */ }
 else {
  BeginUpdate(theWindowPtr);
  /* redraw the window */
  EndUpdate(theWindowPtr);
} 

 Apparently MS Word's code doesn't do this (hey, neither did mine, at
first), but then again, it isn't expecting to have to update windows
other than its own! And curiously enough, everything is just fine when
you run under MF; the program never receives the "extra" window update
event when Moire is deactivated.

 So here's my question: is this a bug in the way WaitNextEvent has been
implemented for UniFinder in 6.0.x?  Or am I experiencing symptoms of
increasing density? :-(

(Sorry about the length, and overuse of the words "we" and "us" :-))
-ken


-- 
==========      .......     ===========================================
Ken McLeod     :.     .:    uucp: {spsd, zardoz, felix}!dhw68k!thecloud
==========    :::.. ..:::   InterNet: thecloud@dhw68k.cts.com
                 ////       ===========================================