cak3g@astsun8.astro.Virginia.EDU (Colin Klipsch) (11/22/89)
Got carried away?! You put your sword right through his head!
Oh dear; is he alright?
-- from "Monty Python and the Holy Grail"
______________________________________________________________________
I just read a recent article in this group which suggested that
the days of jGNEfilter may be numbered. (This is a low memory
global which contains a pointer to an event filter routine.)
This disturbs me since the INIT I've written depends highly on
the existence of jGNEFilter. My program plays 'snd 's based on
various Mac keyboard events. In order to know whether or not
to play a sound and which sound to play, my event filter obviously
must be able to respond to events as they happen.
If I wish to remain compatible with future Macs (as I do in fact), how
does one respond to events without using jGNEFilter? Will there be some
new method? Is there a more subtle way of responding to events of
which I am not aware?
The life or death of my program hangs in the balance...
______________________________________________________________________
"May the forces of evil become confused on the way to your house."
-- George Carlin
Sincerely, | DISCLAIMER:
Colin Klipsch | Every word in this text is
University of Virginia | actually a horrendous misspelling
(cak3g@astsun.astro.virginia.edu) | of the word "fettuccini".tim@hoptoad.uucp (Tim Maroney) (11/24/89)
In article <2323@hudson.acc.virginia.edu> cak3g@astsun8.astro.Virginia.EDU (Colin Klipsch) writes: >I just read a recent article in this group which suggested that >the days of jGNEfilter may be numbered. (This is a low memory >global which contains a pointer to an event filter routine.) The days of all low-memory globals are supposedly numbered, presumably to reduce context switching overhead in future releases of the operating system. >If I wish to remain compatible with future Macs (as I do in fact), how >does one respond to events without using jGNEFilter? Will there be some >new method? Is there a more subtle way of responding to events of >which I am not aware? Sure, just tail patch GetNextEvent! Seriously, the answer to your question is that there is no way to do this kind of thing and be compatible with the guidelines. You can either tail patch, which may break now or soon, or use jGNEfilter, which may break in 1991. I'd go for the latter, that is, keep doing what you're doing now. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "But don't you see, the color of wine in a crystal glass can be spiritual. The look in a face, the music of a violin. A Paris theater can be infused with the spiritual for all its solidity." -- Lestat, THE VAMPIRE LESTAT, Anne Rice
lim@iris.ucdavis.edu (Lloyd Lim) (11/24/89)
In article <9068@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <2323@hudson.acc.virginia.edu> cak3g@astsun8.astro.Virginia.EDU >(Colin Klipsch) writes: >>[...] >>If I wish to remain compatible with future Macs (as I do in fact), how >>does one respond to events without using jGNEFilter? Will there be some >>new method? Is there a more subtle way of responding to events of >>which I am not aware? > >Sure, just tail patch GetNextEvent! Seriously, the answer to your >question is that there is no way to do this kind of thing and be >compatible with the guidelines. You can either tail patch, which may >break now or soon, or use jGNEfilter, which may break in 1991. I'd go >for the latter, that is, keep doing what you're doing now. 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. But you want to play sounds... (BTW, TappyType doesn't play on my IIcx unless I disabled all my INITs. Since it's not life or death, I didn't bother to find out which one it was and I just don't use it.) How about setting a flag in your PostEvent head patches and checking for it in a head patch to GetNextEvent and company? Depending on the flag, you can play your sound(s) before GetNextEvent gets called. It shouldn't matter what event mask the call has since you just want to play sounds whenever a key was previously hit. I haven't fully thought this through but it sounds ok to me. Anyone think of any problems with this? (Hey, if this works, we can start a consulting business here! First we (the collective body of comp.sys.mac.programmers) figure how to make the trash can flush, then we figure out how to make the keyboard into a typewriter! Give us a tail patch and we'll try to come up with some insanely complex clean way to do it! :-) Now watch someone give a reason why my method won't work.) +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
tim@hoptoad.uucp (Tim Maroney) (11/25/89)
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. Seems iffy to me. PostEvent is called at the interrupt level when the frontmost application does not necessarily have control. Scenario: 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 keep track of whether you're in the front or not, but this seems like a fragile patch. Another problem comes in the reverse situation. You could be in front and the PostEvent could happen while another application is getting time. Then your patch won't fire. No way around that. >How about setting a flag in your PostEvent head patches and checking for it in >a head patch to GetNextEvent and company? Depending on the flag, you can play >your sound(s) before GetNextEvent gets called. It shouldn't matter what >event mask the call has since you just want to play sounds whenever a key was >previously hit. Well, except that it requires a PostEvent trap, and the user interface might feel wrong if the event being handled isn't the event for which the sound is desired. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "As I was walking among the fires of Hell, delighted with the enjoyments of Genius; which to Angels look like torment and insanity. I collected some of their Proverbs..." - Blake, "The Marriage of Heaven and Hell"
d88-jwa@nada.kth.se (Jon Watte) (11/25/89)
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
tim@hoptoad.uucp (Tim Maroney) (11/27/89)
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"
lim@iris.ucdavis.edu (Lloyd Lim) (11/27/89)
In article <9085@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. > >[...] > >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. It depends on what model you are trying to achieve. If you want the appropriate sound to occur when the character is being drawn on the screen (or otherwise processed), then my solution will be bad in some cases. However, if you want to emulate the hardware clicking that some terminals do then this should work ok. In this case the sound should occur soon after the key was pressed and in the order the keys were pressed - not in the order the program processes them. It's not uncommon to press a terminal key, hear a click as feedback, and then wait for a couple of seconds for the character to appear when the system is overloaded. I guess it depends which model the author wants to emulate. I think arguments could be made for both. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
tecot@Apple.COM (Ed Tecot) (11/30/89)
In article <9068@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <2323@hudson.acc.virginia.edu> cak3g@astsun8.astro.Virginia.EDU >(Colin Klipsch) writes: >>I just read a recent article in this group which suggested that >>the days of jGNEfilter may be numbered. (This is a low memory >>global which contains a pointer to an event filter routine.) > >The days of all low-memory globals are supposedly numbered, presumably >to reduce context switching overhead in future releases of the >operating system. Or to support (gasp) protected memory in the future without putting the MMU into a tailspin. >>If I wish to remain compatible with future Macs (as I do in fact), how >>does one respond to events without using jGNEFilter? Will there be some >>new method? Is there a more subtle way of responding to events of >>which I am not aware? > >Sure, just tail patch GetNextEvent! Seriously, the answer to your >question is that there is no way to do this kind of thing and be >compatible with the guidelines. You can either tail patch, which may >break now or soon, or use jGNEfilter, which may break in 1991. I'd go >for the latter, that is, keep doing what you're doing now. Much better is to head patch SystemEvent, which gets a chance to filter every event which goes by. _emt
d88-jwa@nada.kth.se (Jon Watte) (12/01/89)
In article <36871@apple.Apple.COM> tecot@Apple.COM (Ed Tecot) writes: >Or to support (gasp) protected memory in the future without putting the MMU >into a tailspin. Yes ! Hear ! Hear ! Way to go, _emt !!! -- -- Stay alert ! - Trust noone ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request