time@ice.com (02/23/91)
In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes: > I can't seem to find any documentation on this one. It appears that > PostEvent can be called at interrupt, so that I can post app1Evt's > from asynchronous completetion routines in my program to signal that > events have occurred. It is not clear, however, how I am to distinguish I believe that with the advent of MultiFinder, applications are not supposed to be using the appEvt's. Unfortunately, I do not have my MF Doc at hand... tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
resnick@cogsci.uiuc.edu (Pete Resnick) (02/23/91)
I can't seem to find any documentation on this one. It appears that PostEvent can be called at interrupt, so that I can post app1Evt's from asynchronous completetion routines in my program to signal that events have occurred. It is not clear, however, how I am to distinguish my app1Evt's from those that might be posted by another application running under Multifinder, or whether I will see these events at all if I have been suspended. Is this documented somewhere, or does anyone know what the story is? Thanks, pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (02/24/91)
In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes: >I can't seem to find any documentation on this one. It appears that >PostEvent can be called at interrupt, so that I can post app1Evt's >from asynchronous completetion routines in my program to signal that >events have occurred. It is not clear, however, how I am to distinguish >my app1Evt's from those that might be posted by another application >running under Multifinder, or whether I will see these events at all >if I have been suspended. Is this documented somewhere, or does anyone >know what the story is? I don't know, but I believe Apple is discouraging developers from using appXEvt's for the purpose you described, since under extreme circumstances, events may be discarded. Maybe it's better to just set a boolean flag which is checked in the main event loop. Matthias -- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
thomas@duteca (Thomas Okken) (02/28/91)
> In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes: >> I can't seem to find any documentation on this one. It appears that >> PostEvent can be called at interrupt, so that I can post app1Evt's >> from asynchronous completetion routines in my program to signal that >> events have occurred. It is not clear, however, how I am to distinguish > > I believe that with the advent of MultiFinder, applications are not > supposed to be using the appEvt's. Unfortunately, I do not have my > MF Doc at hand... Well, I don't remember offhand where I read this - must've been either "Programmer's Guide to MultiFinder" or some technote, but the answer is: You can't use app[1-4]evts under MultiFinder, because all events will be passed to the foreground application. So if your app is in the background, waiting to be notified by an app1evt (to be posted by a VBL task doing some useful thing), it can wait forever: the app1evt is sent to the foreground app, which will probably ignore it. If communication between an interrupt-time task an your application is needed, use globals as semaphores. Have fun trying to keep track of A5! ;-) - Thomas (thomas@duteca.et.tudelft.nl)
resnick@cogsci.uiuc.edu (Pete Resnick) (02/28/91)
thomas@duteca (Thomas Okken) writes: >Well, I don't remember offhand where I read this - must've been either >"Programmer's Guide to MultiFinder" or some technote, but the answer is: >You can't use app[1-4]evts under MultiFinder, because all events will be passed >to the foreground application. So if your app is in the background, waiting >to be notified by an app1evt (to be posted by a VBL task doing some useful >thing), it can wait forever: the app1evt is sent to the foreground app, which >will probably ignore it. This is the second answer I got saying this. Phil Shapiro, from Symantec, says that each application under MF has it's own event queue and that I *will* see app1Evt's. And I went through "Programmer's Guide to MultiFinder" cover to cover and it only said not to use app4Evt's. Can someone get me a definitive answer?!?! pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
mandel@vax.anes.tulane.edu (Jeff E Mandel MD MS) (02/28/91)
In article <1244@duteca4.UUCP> thomas@duteca (Thomas Okken) writes: >> In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes: >>> I can't seem to find any documentation on this one. It appears that >>> PostEvent can be called at interrupt, so that I can post app1Evt's >>> from asynchronous completetion routines in my program to signal that >>> events have occurred. It is not clear, however, how I am to distinguish >> >> I believe that with the advent of MultiFinder, applications are not >> supposed to be using the appEvt's. Unfortunately, I do not have my >> MF Doc at hand... > >Well, I don't remember offhand where I read this - must've been either >"Programmer's Guide to MultiFinder" or some technote, but the answer is: >You can't use app[1-4]evts under MultiFinder, because all events will be passed >to the foreground application. So if your app is in the background, waiting >to be notified by an app1evt (to be posted by a VBL task doing some useful >thing), it can wait forever: the app1evt is sent to the foreground app, which >will probably ignore it. >If communication between an interrupt-time task an your application is needed, >use globals as semaphores. Have fun trying to keep track of A5! ;-) > I have struggled with the problem of passing messages from interrupt-time to eventLoop-time, and my conclusion was that the best solution is to implement your own private event queue as an OSqueue, and have your own routine which does the equivalent of GetNextEvent. I call this routine on null event, and in a DragHook and MenuHook, allowing real-time processes to get serviced even if the user is inconsiderately mousing down when real-time events are occuring. If someone dies and leaves me a month of free time in their will, I think it would make a great INIT to patch the traps that can keep control during mousing so that a real-time process can run on a Mac. Maybe I could win an Apple keychain in the MacHack Hack contest for it. Jeff E Mandel MD MS Asst Professor of Anesthesiology Tulane University School of Medicine New Orleans, LA
ksand@Apple.COM (Kent Sandvik) (03/02/91)
In article <25921@neptune.inf.ethz.ch> mneerach@iiic.ethz.ch writes: >In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes: >>I can't seem to find any documentation on this one. It appears that >>PostEvent can be called at interrupt, so that I can post app1Evt's >>from asynchronous completetion routines in my program to signal that >>events have occurred. It is not clear, however, how I am to distinguish >>my app1Evt's from those that might be posted by another application >>running under Multifinder, or whether I will see these events at all >>if I have been suspended. Is this documented somewhere, or does anyone >>know what the story is? > >I don't know, but I believe Apple is discouraging developers from using >appXEvt's for the purpose you described, since under extreme circumstances, >events may be discarded. Maybe it's better to just set a boolean flag which >is checked in the main event loop. If one app send app1 events, and another app under MF sends app1 events, and the events are sent to the *foremost* window, then everyone sees the problem. System7 with most structured IPC (or IAC in Apple terms) is the way to go. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ was given to mankind, so that we might learn patience"
wdh@well.sf.ca.us (Bill Hofmann) (03/04/91)
In article <25921@neptune.inf.ethz.ch> mneerach@iiic.ethz.ch writes: >In article <1991Feb23.140420.20707@ux1.cso.uiuc.edu>, resnick@cogsci.uiuc.edu (Pete Resnick) writes: >>I can't seem to find any documentation on this one. It appears that >>PostEvent can be called at interrupt, so that I can post app1Evt's >>from asynchronous completetion routines in my program to signal that >>events have occurred. It is not clear, however, how I am to distinguish >>my app1Evt's from those that might be posted by another application >>running under Multifinder, or whether I will see these events at all >>if I have been suspended. Is this documented somewhere, or does anyone >>know what the story is? > >I don't know, but I believe Apple is discouraging developers from using >appXEvt's for the purpose you described, since under extreme circumstances, >events may be discarded. Maybe it's better to just set a boolean flag which >is checked in the main event loop. Yup, Apple now recommends that you do not post events within an application. The problem is, there is only 1 event queue. If you post an event, there's *no* guarantee that you'll get it. If you want to build a message-driven environment, pre-System 7, you need to build your own message queue. That way, you have control (note the other problem, as mentioned, is that since there are only 20 events queued, it's pretty easy to swamp the event queue if you're generating events programmatically. This is why Apple rewrote the AppleTalk manager to stop using networkEvts.) -Bill Hofmann