Xref: utzoo comp.sys.mac:21283 comp.sys.mac.programmer:2672
Path: utzoo!attcan!uunet!husc6!rutgers!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: Moire bug with MS Word 3.02
Message-ID: <18342@apple.Apple.COM>
Date: 6 Oct 88 17:31:04 GMT
References: <882@hub.ucsb.edu> <12606@dhw68k.cts.com>
Organization: Advanced Technology Group, Apple Computer
Lines: 32

In article <12606@dhw68k.cts.com> thecloud@dhw68k.cts.com (Ken McLeod) writes:
>
>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).

If you are not running MultiFinder, then windows are either your windows or
DA windows.  The system doesn't distinguish windows created by INIT code
such as Moire.

> 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 */ }

This can be impractical if your application supports many windows.  

It sounds like a bug in Moire to me.  It seems to be relying on some
feature that is not true in this particular situation.  It really should be
preventing this problem by intercepting update events directed to its window
so that they never get to the application.  It is doing tricky things behind
the application's back, so it has to be responsible for makin the
application happy.

		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr