Path: utzoo!attcan!uunet!mcsun!sunic!draken!d88-jwa From: d88-jwa@nada.kth.se (Jon Watte) Newsgroups: comp.sys.mac.programmer Subject: Re: Death of jGNEFilter? Message-ID: <2397@draken.nada.kth.se> Date: 25 Nov 89 00:32:21 GMT References: <2323@hudson.acc.virginia.edu> <9068@hoptoad.uucp> <6020@ucdavis.ucdavis.edu> <9074@hoptoad.uucp> Reply-To: d88-jwa@nada.kth.se (Jon W{tte) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 32 In article <9074@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <6020@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) writes: >>The best suggestion I can make is that you can head patch PostEvent and >>PPostEvent if your patch doesn't move memory. If you're doing something else >>that doesn't move memory this might work for you. >Your application has been moved to the back in MultiFinder. An idle >event happens on the frontmost application and the mac gives time to >the background applications, including yours. While yours is running, >an interrupt posts a mouse or keyboard event. Your trap patch fires, >telling you that you've gotten an event, even though teh event is >really for someone else. I suppose you could use teh suspend event to Wasn't this a discussion about an INIT ? An INIT that loads at startup time and installs itself in the system heap ? And would not care about "who" was getting the event ? And IF you patch in the application, this STILL isn't a problem, since both a5 and low memory switching is done both on major and minor switches, so your patch would apply only when you were switched in, and the PostEvent was, indeed, intended for you. This is especially true if you use the GetNextEvent patch to actually play the sound, and PostEvent to set a flag for this patch. The sun always shines in my mac h+ -- ====================================================================== ALL of it, NOW ! ====================================================================== If you wanna see my *real* .sig, mail h+@nada.kth.se or h+@proxxi.se