Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!usc!ucsd!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Death of jGNEFilter? Message-ID: <9085@hoptoad.uucp> Date: 27 Nov 89 01:12:01 GMT References: <2323@hudson.acc.virginia.edu> <9068@hoptoad.uucp> <6020@ucdavis.ucdavis.edu> <9074@hoptoad.uucp> <2397@draken.nada.kth.se> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 70 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. In article <9074@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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 In article <2397@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >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 ? You're right, sorry, I overextended some thoughts I'd had about ways applications could handle Command-Period interrupts better by patching PostEvent. The frontmost application issues wouldn't have anything to do with an INIT-installed patch as opposed to an application-installed patch. However, now look at the problems with the GetNextEvent patch. You will play the sound on the next GetNextEvent from anyone, which may not be the frontmost application -- and you still have the problem of not matching the events pulled off the queue by GetNextEvent to the sound desired. This could be a problem with multiple events pending; suppose that, while a spreadsheet is being recalculated, the user gives two menu key commands, each of which has a different sound, and the first menu key command causes an activate event to happen, or brings up a modal dialog. Even assuming you queue what you get from PostEvent and pull your stored events off the queue in order, one per GetNextEvent or WaitNextEvent, this situation will result in the second sound being played at an inappropriate time; either before the activate, or during the modal dialog. >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. No, I think you've missed my point. The PostEvent is called at interrupt level, and as a result, may be called when the running application is not the frontmost application. However, *all* events except idles are events for the frontmost application -- that's how MultiFinder works. So a PostEvent does not necessarily get called in the context of the application the event is destined for. The mouse or keyboard drivers may (in fact, are likely to) call PostEvent when some background application is using its idle time. (I say "are likely to" because, assuming all applications take about the same amount of idle time, then the probability of a PostEvent for the frontmost application happening in the frontmost application context is roughly the reciprocal of the number of applications open.) This latter point is academic, however, since the actual system would not be implemented in this way. Instead of an application-specific patch, an application would just check the event after it was returned from GetNextEvent (or WaitNextEvent). The only exception would be a "benign virus" that could be installed in an existing application file without access to source code. Still, the problems mentioned here do apply to other possible application-specific PostEvent patches, such as the Command-Period patch I was thinking about, so this part of the discussion is not a total waste. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Prisons are built with stones of Law, Brothels with bricks of Religion." - Blake, "The Marriage of Heaven and Hell"