mikeoro@hubcap.clemson.edu (Michael K O'Rourke) (08/21/89)
I have, i hope, a simple question about the notification manager. I have a appletalk program which may receive packets while in the background. One of the options is to use the NM to tell the user when a packet is received when in such a case. if more than one packet is received, then it only queues up a NM task upon the first receive while in the background. My question is this: Is it all right to queue up a NM task (one that blinks icon, beeps, and places mark in apple menu) and yet have the program continue to run until the user chooses to bring to foreground? Right now, when it gets its first packet while in background, it queues up NM task fine. But when it get the next packet in background it either locks or the program comes to foreground for a second and then goes back the background. This does NOT happen if i turn the Not. Man. option off. There may be a bug in my NM code, but i think it is all right. (I made it from example code i have that works, including the TN code from Apple). Anybody had a similiar experience. Am i violating the purpose of the NM by letting the program continue to run without forcing the user to bring the app to foreground before it continues? Thanx, Michael O'Rourke
ech@cbnewsk.ATT.COM (ned.horvath) (08/22/89)
From article <6293@hubcap.clemson.edu>, by mikeoro@hubcap.clemson.edu (Michael K O'Rourke): > if more than one packet is received, then it only > queues up a NM task upon the first receive while in the background. ... > Is it all right to queue up a NM task (one that blinks icon, beeps, and > places mark in apple menu) and yet have the program continue to run > until the user chooses to bring to foreground? Right now, when it gets its > first packet while in background, it queues up NM task fine. But when it get > the next packet in background it either locks or the program comes to > foreground for a second and then goes back the background. This does NOT > happen if i turn the Not. Man. option off... There's no problem continuing to run with a NM task queued. However, given all the rest, I'd question your assertion that you only queue the NM task once. I'm REAL careful to not queue the second task a second time. Also, under what circumstances do you enqueue the NM task? Remember that AppleTalk listeners, completion routines, etc., operate at interrupt time, with all the restrictions that apply to such routines. Best policy is to simply "make a note" (you'll need SetUpA5()/RestoreA5() in the completion routine) that notification is necessary, then queue the NM task from your main event loop. Hope that helps... =Ned Horvath=
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/22/89)
In article <879@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes:
_>Also, under what circumstances do you enqueue the NM task? Remember
_>that AppleTalk listeners, completion routines, etc., operate at interrupt
_>time, with all the restrictions that apply to such routines. Best policy
_>is to simply "make a note" (you'll need SetUpA5()/RestoreA5() in the
_>completion routine) that notification is necessary, then queue the NM task
_>from your main event loop.
Beware, most of the versions of SetUpA5(), RestoreA5() that are out there
are not multifinder compatible. Read the source code! if it references
CurrentA5 or 0x904, it will bomb under multifinder (since this low memory
global holds not the base of _your_ globals, but of whatever program is
running _now_.
One that will work: Take the file SetUpA4.h that comes with THINK C.
Copy it. Change all references to A4 to references to A5.
It has been claimed that this is not compatible with the 68020's
instruction cache, or that this is self-modifying code. Both claims are
rubbish: data fetches don't go through the I-cache, and self-modifying
code refers to modifying instructions not data.
It has been claimed that it is incompatible with some future Mac O.S. that
will write-protect code. Also rubbish. If this fear bothers you, then put
the code in a resource of some type of your own creation.
--- David Phillip Oster --"Unix Version 7 was an improvement not
Arpa: oster@dewey.soe.berkeley.edu --only over its predeccessors, but also its
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --successors."tecot@Apple.COM (Ed Tecot) (08/30/89)
In article <879@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: >Also, under what circumstances do you enqueue the NM task? Remember >that AppleTalk listeners, completion routines, etc., operate at interrupt >time, with all the restrictions that apply to such routines. Best policy >is to simply "make a note" (you'll need SetUpA5()/RestoreA5() in the >completion routine) that notification is necessary, then queue the NM task >from your main event loop. Actually, there is no need to do this. The Notification Manager routines are not subject to the restrictions imposed upon interrupt routines; feel free to call NMInstall to your heart's content. _emt
tracyn@dgp.toronto.edu (Tracy Narine) (11/18/90)
Newsgroups: comp.sys.mac.programmer Subject: Notification Manager question Expires: References: Sender: Followup-To: Distribution: na Organization: CSRI, University of Toronto Keywords: I am currently writing a driver that uses the notification manager. I am trying to incorporate a response procedure into my code(for the notification manager). The problem I have run into is how do I access my globals in the response procedure. My globals are stored in a structure. When you call NMInstall(x), we have x = QElemPtr. In technote 184 though, it shows you pass in (QElemPtr) &myNote where myNote is a NMRec. I can understand why this is done since the first three fields of NMRec seem to be the same as the fields for a QElemPtr. You can store the location of the globals in a field of the NMRecord. When, the response procedure is called, the parameter passed in is a QElemPtr. This QElemPtr of the response procedure should point me somehow to the original NMRec where I stored my globals, but I am unsure how. If anyone knows how I should access my NNRec please email me or post news. tracy
ml10+@andrew.cmu.edu (Michael A. Libes) (11/19/90)
>When, the response procedure is called, the parameter passed in is a >QElemPtr. This QElemPtr of the response procedure should point me somehow >to the original NMRec where I stored my globals, but I am unsure how. > >If anyone knows how I should access my NNRec please email me or post news. The OS never copies your NMRec, it just adjusts the first three fields which happen to be the same or all OS queues. Therefore you can have as much data after the first three fields as you wish. There are two ways to pass variables to your callback routine. The first way is to create a new record whose first field is a NMRec and other fields are your required globals. For NMRecs, however, Apple provides an extra field for your use. The last field of the nmRec is: nmRefCon: LONGINT; {for application use} Put a pointer (or handle) to your globals, or a pointer to a struct containing the globals you plan on using in the nmRefCon. ------------------------------------------------------------------ Michael Libes (Luni) Internet Address: MacMach Project ml10@andrew.cmu.edu Carnegie Mellon University ------------------------------------------------------------------