Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!tank!nucsrl!jln
From: jln@eecs.nwu.edu (John Norstad)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Multifinder: how do I patch GetNextEvent?
Message-ID: <10050024@eecs.nwu.edu>
Date: 10 Oct 88 20:54:04 GMT
References: <747@ttrdf.UUCP>
Organization: Northwestern U, Evanston IL, USA
Lines: 53


>    What is the proper way to patch the GetNextEvent() trap for
> compatibility with MultiFinder?.  I have created an INIT that
> patches this call. The first thing that the patch does is call the
> old GetNextEvent, (the one that was there at INIT time.). 
> The purpose of the patch is to translate the CapsLock modifier into
> the command-key modifier.
>    My patch still seems to be in there (the desired result occurs), but 
> it introduces long delays and curious behaviour when running under MultiFinder. 
> The two specific weird things are :
>    1) If I have the Finder as the top window, and then obscure an icon on
>       the desktop, then expose it again, the icon  does NOT get redrawn until
>       it gets selected again.
>    2) While running LightSpeed C's debugger, if I enter an expression in the
>       Data window, the watch cursor comes up, and stays there forever,
>       UNTIL you mouse-down a few times on another application's window.
>       Then when you re-activate the debugger window the expresion in the
>       data window is correctly evaluated and displayed.
> 
>   I am running from System Tools 5.0. (The first official Multifinder).
> All above behaviour ceases if I either remove my INIT, or run without
> MultiFinder.
> 
> Any ideas?
> 
> Frank Owen (..!att!ttrdf!fjo)

I had exactly the same problem, and posted a note on comp.sys.mac on August 3.
For your edification, here's the relevant part of my earlier note:

I recently patched GetNextEvent, and noticed that under MultiFinder it wasn't
working quite perfectly.  Under MF, when a desktop icon (disk or trash) was
uncovered after a window drag, it wasn't being redrawn.  After much 
investigation I discovered that in this particular circumstance MF was
expecting GetNextEvent to return a full zero word if the function result was
false.  This is much stricter than the usual rule for Boolean values on the
stack, which says that only the low-order bit of the high-order byte of the
word is significant.  The ROM version of GetNextEvent does indeed always 
return a full zero word if the function result is false, but my patch, which
was written in a high-level language, was only setting the high-order byte
of the function result.  I added some in-line assembly language code to clear
the low-order byte, and this fixed the problem.

You should also pay heed to Bob Hablutzel's reply to your note.  These
so-called "tail patches" are frowned upon.  In the case of System 6.0, which
I use, GetNextEvent is not involved in any of the "come from" patches, so it's
OK to write your own tail patch.  But it may break in future releases.

John Norstad
Academic Computing and Network Services
Northwestern University

Bitnet:   JLN@NUACC
Internet: JLN@NUACC.ACNS.NWU.EDU