Xref: utzoo comp.sys.mac:21505 comp.sys.mac.programmer:2759 Path: utzoo!dciem!nrcaer!scs!mitel!uunet!munnari!jkjl From: jkjl@munnari.oz (John Lim) Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: Re: Moire bug with MS Word 3.02 Message-ID: <2449@munnari.oz> Date: 10 Oct 88 07:35:55 GMT Article-I.D.: munnari.2449 References: <882@hub.ucsb.edu> <12606@dhw68k.cts.com> <18342@apple.Apple.COM> Organization: Comp Sci, Melbourne Uni, Australia Lines: 84 Summary: moire or os bug ? In article <18342@apple.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes: > 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. > Moire's window is a psuedo-DA window in the sense that the windowKind field is mapped to the moire driver. Thus i dont examine every event to see if it is for moire explicitly. I let the os pass all da events to me. > > 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. > Hypothesis : Still to be confirmed. ---------- The story gets complicated now. There is a feature in MF that causes it to give more time to DAs when update events are ignored. Moire 1.41 correctly handled update events, but performance in the Finder layer of MF was terrible because das are 10th class citizens under Finder in MF. Thus the fix was to refuse to clear the updateRgn, and thus performance of Moire improved as the os gave more time to moire in the form of additional update events. This Moire 2.1 refusal to handle update events must be confusing the os (and me). Because there are 3 ways to get events, GetNextEvent, EventAvail, and WaitNextEvent, the event handling mechanism might get out of synch. For example Moire closes a window because it detects mouse movement. This is done by patching getNextEvent. Meanwhile, WaitNextEvent is called by the application. WaitNextEvent is not in synch with GetNextEvent, and passes the old update event to the application, with the message field pointing to an invalid window. Conversely, if the application had called GetNextEvent, everything would probably be fine because i closed the window in a getnextevent patch, so the next call by Word or whatever to GNE would be in synch. Remember this is a hypothesis which i just cooked up while typing this in. I have to test it at home, but i'm 80% confident that that is what has been happening. Strangely enough, this bug only occurs in UniFinder, not in MF as you would expect. If anyone understands what i just said, congrats... It's so complicated because of bugs in applications that i have to work around, while still attempting to be a friendly guest of the host os. > 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. > Quite right, larry. I've covered my ass in two ways now in Moire 2.2. (1). I explicitly check for Finder now. When i'm in the Finder layer, i ignore update events. In other layers, i obey update events like normal. Fortunately, normal applications give moire sufficient time to run - why doesnt finder ???? (2). I explicitly check the update events now. If the message is an invalid pointer, I correct the pointer. > 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 John Lim ps : i suspect that moire will break when we get real os with memory protection and pre-emptive multitasking. I makes me depressed to think that all our long messages and hard work will come to naught when Juggler/2 comes out ;-(