rothberg@polya.Stanford.EDU (Edward Rothberg) (08/02/88)
Thanks for all the responses to the Ticks question. I'm convinced; I'll use the TickCount() trap call. I've also become convinced that MultiFinder doesn't deal with the foreground application's event mask properly. I have an application where I need to receive keyUp events. I call SetEventMask() with the appropriate parameter. My application works perfectly with UniFinder, and it works just fine when I'm running alone (just it and the Finder) in MultiFinder. However, when I start up another application in the background, the foreground application starts losing keyUp events. My guess as to what's happening is that my application is getting switched out, and MultiFinder is substituting the background application's event mask for mine. Anyone know what's going on and how to get around it? Thanks, Ed Rothberg rothberg@polya.stanford.edu
tecot@Apple.COM (Ed Tecot) (08/12/88)
In article <3469@polya.Stanford.EDU> rothberg@polya.Stanford.EDU (Edward Rothberg) writes: >I've also become convinced that MultiFinder doesn't deal with the foreground >application's event mask properly. I have an application where I need to >receive keyUp events. I call SetEventMask() with the appropriate parameter. >My application works perfectly with UniFinder, and it works just fine when >I'm running alone (just it and the Finder) in MultiFinder. However, when I >start up another application in the background, the foreground application >starts losing keyUp events. My guess as to what's happening is that my >application is getting switched out, and MultiFinder is substituting the >background application's event mask for mine. Anyone know what's going on and >how to get around it? The system event mask is a system property, not an application property. The reson for this is that the event mask gets applied when the event is posted, not retrieved. Its use really does not entirely make sense in the MultiFinder environment. However, to answer your question, MultiFinder does not switch the system event mask for each application. Chances are that the application you launch sets the system event mask itself. Setting the event mask on every resume event and restoring it on every suspend event may prove to be a workable solution. _emt
dee@cca.CCA.COM (Donald Eastlake) (08/12/88)
In article <15452@apple.Apple.COM> tecot@apple.com.UUCP (Ed Tecot) writes: >In article <3469@polya.Stanford.EDU> rothberg@polya.Stanford.EDU (Edward Rothberg) writes: >> . . . I call SetEventMask() with the appropriate parameter. >>My application works perfectly with UniFinder, and it works just fine when >>I'm running alone (just it and the Finder) in MultiFinder. However, when I >>start up another application in the background, the foreground application >>starts losing keyUp events. . . . >The system event mask is a system property, not an application property. The >reson for this is that the event mask gets applied when the event is posted, >not retrieved. Its use really does not entirely make sense in the MultiFinder >environment. >However, to answer your question, MultiFinder does not switch the system >event mask for each application. Chances are that the application you launch >sets the system event mask itself. This sounds like nonsense to me. Many applications diddle the System Event Mask a little. Inside MacIntosh gives the application complete licence to turn on or off at least the key-up bit in this Mask although it discourages diddling anything else. (If you are claiming that events in the system event queue are the property of the "system" until an application actually senses them with Get/Wait/Avail then applications should also refrain from ever doing a FlushEvents, at least under MultiFinder (oops, I forgot you are never supposed to check if you are under MutiFinder. I guess you are supposed to check the "system owns the system event queue" service ....)) If MultiFinder does not handle this properly by giving applications the impression that they own the machine when it easily could, I think its a bug in MultiFinder. -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@CCA.CCA.COM usenet: {cbosg,decvax,linus}!cca!dee P. O. Box N, MIT Branch P. O., Cambridge, MA 02139-0903 USA
tecot@Apple.COM (Ed Tecot) (08/31/88)
In article <32058@cca.CCA.COM> dee@CCA.CCA.COM (Donald Eastlake) writes: >In article <15452@apple.Apple.COM> tecot@apple.com.UUCP (Ed Tecot) writes: >>However, to answer your question, MultiFinder does not switch the system >>event mask for each application. Chances are that the application you launch >>sets the system event mask itself. > >This sounds like nonsense to me. You're right. The above statement was wrong. After checking a little further, I found out that MultiFinder DOES in fact switch the event mask. I responded with the way I thought it should work as opposed to the way it does. >(If you are claiming that events in the system event queue are the >property of the "system" until an application actually senses them with >Get/Wait/Avail then applications should also refrain from ever doing a >FlushEvents, at least under MultiFinder (oops, I forgot you are never >supposed to check if you are under MultiFinder. I guess you are supposed >to check the "system owns the system event queue" service ....)) How did you handle desk accessories prior to MultiFinder? What's to stop them from changing the system event mask? _emt