From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-072 Date: Fri, 2 Dec 1994 16:35:30 +0100 (MET) C.S.M.P. Digest Fri, 02 Dec 94 Volume 3 : Issue 72 Today's Topics: ADSP, PPC, Apple Events ? Which to use? ASLM, CFM, etc Background Only Apps Call PostEvent() from a TimeMgr task! OSACompile and OSAExecute PBCatSearch finder flags? Q: SICompletionUPP The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From gerrard@luga.latrobe.edu.au (Graeme Gerrard) Subject: ADSP, PPC, Apple Events ? Which to use? Date: Fri, 11 Nov 1994 13:51:40 GMT Organization: LaTrobe University I need to send messages to a number of Macintoshes connected to a host over Localtalk. The remote Macs will be running the *same program* continuously and different messages need to be sent to them. The messages are short, a couple of hundred bytes each and have to be sent every second or so. The main criteria is robustness. The system has to run, with a minimum of maintenance, for several months. Which is the best way to go, Apple Events, PPC toolbox, or a combination of NBP and ADSP? Advice from anyone with experience in this kind of thing would be greatly appreciated. -- Graeme Gerrard G.Gerrard@latrobe.edu.au Music Dept La Trobe University +++++++++++++++++++++++++++ >From stevec@jolt.mpx.com.au (Stephen Coy) Date: Sun, 13 Nov 1994 00:23:28 +1100 Organization: Resolve Software (WA) Pty Ltd In article , gerrard@luga.latrobe.edu.au (Graeme Gerrard) wrote: > I need to send messages to a number > of Macintoshes connected to a host over Localtalk. > > The remote Macs will be running the *same program* continuously > and different messages need to be sent to them. > The messages are short, a couple of hundred bytes each > and have to be sent every second or so. > The main criteria is robustness. The system has to run, with a minimum of > maintenance, for several months. > > Which is the best way to go, Apple Events, PPC toolbox, or a combination > of NBP and ADSP? > > Advice from anyone with experience in this kind of thing would be > greatly appreciated. > Given the frequency of your messages, I would be inclined to build on top of the PPC toolbox. Combining this with the Threads Manager will allow your applications to function pseudo-asynchronously, independently of the Event Manager. The PPC toolbox provides functionality that you would have to build anyway if you were to build your own stuff on top of ADSP/NBP. I suspect that the AppleEvent Manager would have trouble with the volume. -- Steve Coy Resolve Software (WA) Pty Ltd 4/69 Lynwood Ave Dee Why NSW 2099 Australia +++++++++++++++++++++++++++ >From h+@metrowerks.com (Jon W{tte) Date: Sun, 13 Nov 1994 11:16:47 +0100 Organization: The Conspiracy In article , gerrard@luga.latrobe.edu.au (Graeme Gerrard) wrote: >The main criteria is robustness. The system has to run, with a minimum of >maintenance, for several months. >Which is the best way to go, Apple Events, PPC toolbox, or a combination >of NBP and ADSP? >Advice from anyone with experience in this kind of thing would be >greatly appreciated. For the criteria mentioned, you can use any one of the methods. NBP/ADSP is the most work, and the easiest on the network. AppleEvents are much easier to code, but take more bandwidth. PPC is just in the middle of them. I would use AppleEvents because they're safe and easy to debug. What worries me is this: >I need to send messages to a number >of Macintoshes connected to a host over Localtalk. >The messages are short, a couple of hundred bytes each >and have to be sent every second or so. LocalTalk has a MAXIMUM data throughput of 25 kB per second. You have to divide by at least two, probably four, to get a reliably sustainable data rate without too many collissions. Two for the collission evasion on an ether media (not Ethernet, but any CSMD media like LocalTalk), and two more for overhead in protocols and replies. This gives you 6 kB/sec, or about 12 macs with 500 byte messages. Max. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Santa's Reindeer: Fry 1 minced onion, add 1 lb thinly sliced frozen reindeer, fry to color, add 1/2 lb mushrooms and 1/2 lb sour cream, simmer 5 mins, add soy to taste, salt, pepper. Serve with boiled rice and redcurrant jelly. +++++++++++++++++++++++++++ >From pgontier@novell.com (Pete Gontier) Date: Mon, 14 Nov 1994 20:32:55 -0800 Organization: Novell, Inc., Walnut Creek/Macintosh Site In article , gerrard@luga.latrobe.edu.au (Graeme Gerrard) wrote: > I need to send messages to a number > of Macintoshes connected to a host over Localtalk. > > ...The main criteria is robustness.... > > Which is the best way to go, Apple Events, PPC toolbox, or a combination > of NBP and ADSP? Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is based on ADSP. You probably already knew this, but sometimes it's useful to hear it out loud. What it means is that no matter which of the three you pick, your choice will only be as robust as ADSP, but might be less robust. This might lead you to go with ADSP, if only to reduce the number of layers involved. However, PPC Toolbox does buy you quicker comm between processes on the same Mac, and AppleEvents buy you some amount of simplification, which might end up meaning that the least tested code, yours, is more robust. -- The views expressed here do not necessarily reflect those of my employer. "Furthermore, in my mad haste to switch CDs, I dragged the Inside Mac CD-ROM icon to the trash and when the Mac ejected it, the tray pushed a glass of grape juice off my desk and into my lap. Let that be a lesson to development tool vendors: all this would have been avoided with better documentation." -- Miguel Cruz +++++++++++++++++++++++++++ >From bdiamand@netcom.com (Ben Diamand) Date: Wed, 16 Nov 1994 03:44:59 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Pete Gontier (pgontier@novell.com) wrote: : In article , : gerrard@luga.latrobe.edu.au (Graeme Gerrard) wrote: : > I need to send messages to a number : > of Macintoshes connected to a host over Localtalk. : > : > ...The main criteria is robustness.... : > : > Which is the best way to go, Apple Events, PPC toolbox, or a combination : > of NBP and ADSP? : Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is : based on ADSP. You probably already knew this, but sometimes it's useful : to hear it out loud. What it means is that no matter which of the three : you pick, your choice will only be as robust as ADSP, but might be less : robust. This might lead you to go with ADSP, if only to reduce the number : of layers involved. However, PPC Toolbox does buy you quicker comm between : processes on the same Mac, and AppleEvents buy you some amount of : simplification, which might end up meaning that the least tested code, : yours, is more robust. Also be aware that ADSP in built on top of DDP. Now I know that ddp is lower level than most want to go, BUT, if you minimum overhead and still maintain compatability, you might consider DDP as an option. One fault of DDP is that it's connection-less, meaning packets can be lost, so if you can't afford that, ADSP is the way to go... Ben Diamand bdiamand@netcom.com +++++++++++++++++++++++++++ >From Chris Russo Date: 17 Nov 1994 01:56:47 GMT Organization: Sonic Systems, Inc. In article Graeme Gerrard, gerrard@luga.latrobe.edu.au writes: >I need to send messages to a number >of Macintoshes connected to a host over Localtalk. > >The remote Macs will be running the *same program* continuously >and different messages need to be sent to them. >The messages are short, a couple of hundred bytes each >and have to be sent every second or so. >The main criteria is robustness. The system has to run, with a minimum of >maintenance, for several months. > >Which is the best way to go, Apple Events, PPC toolbox, or a combination >of NBP and ADSP? > >Advice from anyone with experience in this kind of thing would be >greatly appreciated. Go with NBP and ADSP. Anecdote*: My office-mate wrote Server Sentry, a remote AppleShare admin, using AppleEvents - at first. Unfortunately, he found that AppleEvents sent to a very busy machine can die without notifying the sender of the error. He then took a step back to rely on the PPC toolbox. Then, you still have to mess with program linking's dialogs since the PPC toolbox doesn't allow you to authenticate a user programmatically. He ended up having to patch GetNewDialog() to hide Program Linking's password dialog offscreen while he stuffed the user's name and password into the dialog by posting the events. Yuck. Stick with ADSP. It's a little nitty grittier, but simplicity of a protocol can have a lot of advantages. Better to spend a little extra time getting started with a project because the building blocks are smaller than to start with a higher level protocol then get stuck mid-project because the protocol lacks some functionality. Then you have to hack the hell out of the thing. See the previous example. Of course, you might not want to take my word for it. I like to use DDP whenever I can. :-) * Don't blame me for technical inaccuracies in this anecdote. If necessary, I'll post the source of these complaints to avoid being flamed. :-) Thanks, - ------------------------------------------------------------------------ Chris Russo Macintosh Programmer Sonic Systems, Inc. (408) 736-1900 #107 chris@sonicsys.com I'm tired of my signature. +++++++++++++++++++++++++++ >From bdiamand@netcom.com (Ben Diamand) Date: Wed, 16 Nov 1994 03:44:59 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Pete Gontier (pgontier@novell.com) wrote: : In article , : gerrard@luga.latrobe.edu.au (Graeme Gerrard) wrote: : > I need to send messages to a number : > of Macintoshes connected to a host over Localtalk. : > : > ...The main criteria is robustness.... : > : > Which is the best way to go, Apple Events, PPC toolbox, or a combination : > of NBP and ADSP? : Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is : based on ADSP. You probably already knew this, but sometimes it's useful : to hear it out loud. What it means is that no matter which of the three : you pick, your choice will only be as robust as ADSP, but might be less : robust. This might lead you to go with ADSP, if only to reduce the number : of layers involved. However, PPC Toolbox does buy you quicker comm between : processes on the same Mac, and AppleEvents buy you some amount of : simplification, which might end up meaning that the least tested code, : yours, is more robust. Also be aware that ADSP in built on top of DDP. Now I know that ddp is lower level than most want to go, BUT, if you minimum overhead and still maintain compatability, you might consider DDP as an option. One fault of DDP is that it's connection-less, meaning packets can be lost, so if you can't afford that, ADSP is the way to go... Ben Diamand bdiamand@netcom.com +++++++++++++++++++++++++++ >From bdiamand@netcom.com (Ben Diamand) Date: Wed, 16 Nov 1994 03:44:59 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Pete Gontier (pgontier@novell.com) wrote: : In article , : gerrard@luga.latrobe.edu.au (Graeme Gerrard) wrote: : > I need to send messages to a number : > of Macintoshes connected to a host over Localtalk. : > : > ...The main criteria is robustness.... : > : > Which is the best way to go, Apple Events, PPC toolbox, or a combination : > of NBP and ADSP? : Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is : based on ADSP. You probably already knew this, but sometimes it's useful : to hear it out loud. What it means is that no matter which of the three : you pick, your choice will only be as robust as ADSP, but might be less : robust. This might lead you to go with ADSP, if only to reduce the number : of layers involved. However, PPC Toolbox does buy you quicker comm between : processes on the same Mac, and AppleEvents buy you some amount of : simplification, which might end up meaning that the least tested code, : yours, is more robust. Also be aware that ADSP in built on top of DDP. Now I know that ddp is lower level than most want to go, BUT, if you minimum overhead and still maintain compatability, you might consider DDP as an option. One fault of DDP is that it's connection-less, meaning packets can be lost, so if you can't afford that, ADSP is the way to go... Ben Diamand bdiamand@netcom.com +++++++++++++++++++++++++++ >From Chris Russo Date: 17 Nov 1994 01:56:47 GMT Organization: Sonic Systems, Inc. In article Graeme Gerrard, gerrard@luga.latrobe.edu.au writes: >I need to send messages to a number >of Macintoshes connected to a host over Localtalk. > >The remote Macs will be running the *same program* continuously >and different messages need to be sent to them. >The messages are short, a couple of hundred bytes each >and have to be sent every second or so. >The main criteria is robustness. The system has to run, with a minimum of >maintenance, for several months. > >Which is the best way to go, Apple Events, PPC toolbox, or a combination >of NBP and ADSP? > >Advice from anyone with experience in this kind of thing would be >greatly appreciated. Go with NBP and ADSP. Anecdote*: My office-mate wrote Server Sentry, a remote AppleShare admin, using AppleEvents - at first. Unfortunately, he found that AppleEvents sent to a very busy machine can die without notifying the sender of the error. He then took a step back to rely on the PPC toolbox. Then, you still have to mess with program linking's dialogs since the PPC toolbox doesn't allow you to authenticate a user programmatically. He ended up having to patch GetNewDialog() to hide Program Linking's password dialog offscreen while he stuffed the user's name and password into the dialog by posting the events. Yuck. Stick with ADSP. It's a little nitty grittier, but simplicity of a protocol can have a lot of advantages. Better to spend a little extra time getting started with a project because the building blocks are smaller than to start with a higher level protocol then get stuck mid-project because the protocol lacks some functionality. Then you have to hack the hell out of the thing. See the previous example. Of course, you might not want to take my word for it. I like to use DDP whenever I can. :-) * Don't blame me for technical inaccuracies in this anecdote. If necessary, I'll post the source of these complaints to avoid being flamed. :-) Thanks, - ------------------------------------------------------------------------ Chris Russo Macintosh Programmer Sonic Systems, Inc. (408) 736-1900 #107 chris@sonicsys.com I'm tired of my signature. +++++++++++++++++++++++++++ >From pjd@triassic.midnight.com (Peter Desnoyers) Date: 18 Nov 94 15:06:14 Organization: Midnight Networks Inc., Waltham MA In article h+@metrowerks.com (Jon W{tte) writes: > >LocalTalk has a MAXIMUM data throughput of 25 kB per second. >You have to divide by at least two, probably four, to get a >reliably sustainable data rate without too many collissions. >Two for the collission evasion on an ether media (not Ethernet, >but any CSMD media like LocalTalk), and two more for overhead >in protocols and replies. This gives you 6 kB/sec, or about 12 >macs with 500 byte messages. You might want to go back and check your math on that one. Localtalk is actually quite efficient - if you send max size packets on a loaded net, you will have 400us of inter-frame gap, followed by an average of 6 RTS transmissions (actually 2e) until one is ACKed successfully, at 200us each, followed by 20 ms of data. That's an efficiency of about 93%. (not counting framing and protocol overhead). Overhead goes up with smaller packets, but you could still get about 80% efficiency with 200-byte packets. [also, the max data rate on LocalTalk is 230kb/8 = ~29kbyte/sec.] As far as higher-layer protocol overhead goes, 2x seems like an overly high estimate, but with the right protocol I'm sure you could make it even worse than that. ............................................................................... Peter Desnoyers : Midnight Networks Inc. 200 Fifth Avenue Waltham MA 02154 pjd@midnight.com : Vox 617/890-1001 Fax -0028 The Best in Network Software -- ............................................................................... Peter Desnoyers : Midnight Networks Inc. 200 Fifth Avenue Waltham MA 02154 pjd@midnight.com : Vox 617/890-1001 Fax -0028 The Best in Network Software --------------------------- >From erik@lexmark.com (Erik Ackerman) Subject: ASLM, CFM, etc Date: Wed, 16 Nov 1994 18:14:57 GMT Organization: AiC I am working on a rewrite of an application that would greatly benefit from being "plugable". I have been aiming for a code resource spec, but recently began to consider using ASLM or CFM (need to support 68K). Does anyone have any recomendations as to what solution would be best? Which will have the greatest longevity and/or support? etc... Thanks in advance. Erik Ackerman -- erik@lexmark.com Q: What is the difference between a duck? A: One of its legs is both the same. +++++++++++++++++++++++++++ >From untulis@netcom.com (Jason Untulis) Date: Wed, 16 Nov 1994 20:12:22 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Erik Ackerman (erik@lexmark.com) wrote: : I am working on a rewrite of an application that would greatly benefit from : being "plugable". I have been aiming for a code resource spec, but : recently began to consider using ASLM or CFM (need to support 68K). Does : anyone have any recomendations as to what solution would be best? Which : will have the greatest longevity and/or support? etc... >From what I've read, CFM would be your best bet. ASLM is dependent on cfront C++-style name mangling, whereas CFM should work with any language. CFM alread exists on PPC, with the beta 68K CFM coming with the OpenDoc beta which is scheduled for January. I would think that CFM is the thing that will ge the most support from Apple. -- - ----- #include (C) 1994. All rights reserved. Jason Untulis untulis@ (netcom.com) (tower.tandem.com) untulis_jason@tandem.com, jason@hplcau.hpl.hp.com "You don't want to upset the dinosaurs, do you?" -- CompuServe ad +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 17 Nov 1994 16:20:06 -0500 Organization: America Online, Inc. (1-800-827-6364) In article , erik@lexmark.com (Erik Ackerman) writes: >I am working on a rewrite of an application that would greatly benefit from >being "plugable". I have been aiming for a code resource spec, but >recently began to consider using ASLM or CFM (need to support 68K). Does >anyone have any recomendations as to what solution would be best? Which >will have the greatest longevity and/or support? etc... The answer probably depends upon other requirements. Do you require C++? Do you require the ability to develop your "plugs" with several different compilers? If you require C++, then you should either use ASLM, which limits the compilers you can use, or you should use SOM on top of CFM. If you don't require C++, then straight CFM is probably your best choice. If you try to use C++ on CFM you'll probably be forced to use a single compiler, and you'll have to worry about the "fragile base class" problem. If you use SOM, then you'll (in theory) be able to write plugs in multiple languages/compilers, and the fragile base class problem is almost completely solved. SOM language bindings for C and C++ are available now, and other languages will probably be supported in the future. Note that the SOM object model is very similar to Object Pascal's object model, so you give up some of the features of C++, e.g. no stack-based objects (but you can have multiple inheritance). Also note that you can use SOM for your exported interface, but internally use all the features C++ if you so choose. By the way, OpenDoc is being built with SOM/CFM. One question you should answer is: can your application be built using OpenDoc? Jim Lloyd afcjlloyd@aol.com +++++++++++++++++++++++++++ >From mattm@apple.com (Matthew Melmon) Date: Thu, 17 Nov 1994 20:28:53 GMT Organization: Cabal Noir: Glorious Leader In article , untulis@netcom.com (Jason Untulis) wrote: > Erik Ackerman (erik@lexmark.com) wrote: > : I am working on a rewrite of an application that would greatly benefit from > : being "plugable". I have been aiming for a code resource spec, but > : recently began to consider using ASLM or CFM (need to support 68K). Does > : anyone have any recomendations as to what solution would be best? Which > : will have the greatest longevity and/or support? etc... > > From what I've read, CFM would be your best bet. ASLM is dependent on > cfront C++-style name mangling, whereas CFM should work with any language. > CFM alread exists on PPC, with the beta 68K CFM coming with the OpenDoc > beta which is scheduled for January. I would think that CFM is the > thing that will ge the most support from Apple. A really, really, really close-to-beta (RRRCtB) of CFM-68K will be shipping on ETO 16, in a matter of weeks, now, I suppose. -- *X* --------------------------- >From ctaylor@fox.nstn.ns.ca (Christian Taylor) Subject: Background Only Apps Date: 7 Nov 1994 16:45:24 -0400 Organization: Nova Scotia Technology Network Could someone please send me some sample source code of a background only app in Pascal? (THINK Pascal actually). Everytime I try to make a program background only, the Mac crashes whenever I click in the Application menu! And yes, I've read the Tech Note from ftp.apple.com on BOAs. Thanks! Christian +++++++++++++++++++++++++++ >From williar2@miavx1.acs.muohio.edu (Bob Williams) Date: 7 Nov 94 19:34:03 -0500 Organization: Enterprise Software In article , ctaylor@fox.nstn.ns.ca (Christian Taylor) writes: > Could someone please send me some sample source code of a background only > app in Pascal? (THINK Pascal actually). Everytime I try to make a > program background only, the Mac crashes whenever I click in the > Application menu! And yes, I've read the Tech Note from ftp.apple.com on > BOAs. Thanks! > > Christian Me too!!! I have the exact same problem. I posted here once before, but noone answered. I would greatly appreciate it. Thanks!!! Regards, Bob -- +------------------------------------------------------+ | Robert E. Williams, Jr. | | Enterprise Software | | 2006 State Route 380 | | Wilmington, Ohio 45177-9241 | | (513) 382-8232 | | | | E-mail: williar2@miavx1.acs.muohio.edu | +------------------------------------------------------+ | Those who are patient in the trivial things in | | life and control themselves will one day have the | | same mastery in great and important things. | | --Hapkido Master Bong Soo Han | +------------------------------------------------------+ +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Tue, 08 Nov 1994 22:23:24 +1200 Organization: AucklandUniversity:ComputerScience:HMU In article <1994Nov7.193403.33348@miavx1>, williar2@miavx1.acs.muohio.edu (Bob Williams) wrote: > In article , ctaylor@fox.nstn.ns.ca (Christian Taylor) writes: > > Could someone please send me some sample source code of a background only > > app in Pascal? (THINK Pascal actually). Everytime I try to make a > > program background only, the Mac crashes whenever I click in the > > Application menu! And yes, I've read the Tech Note from ftp.apple.com on > > BOAs. Thanks! > > Me too!!! I have the exact same problem. I posted here once before, but noone > answered. I would greatly appreciate it. Thanks!!! THINK Pascal automagically places standard toolbox initialization code at the beginning of your app. You need to turn this feature off for BOAs by placing a {$I-} near the top of your main program file. You also need a _MaxApplZone call (expands heap to fullest), an _InitGraf call (sets up your app A5 world) and a few _MoreMasters (to preallocate a few master pointer blocks). Your code goes after this stuff. {-------------------------} {$I-} program blah; begin MaxApplZone; InitGraf(@thePort); MoreMasters; MoreMasters; MoreMasters; end. {-------------------------} Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 Async, therefore I am. - --------------------------------------------------------------------- +++++++++++++++++++++++++++ >From asunta@convex.csc.FI (Miika Asunta) Date: 12 Nov 1994 17:08:43 GMT Organization: Sibelius Academy, Helsinki In <1994Nov7.193403.33348@miavx1> williar2@miavx1.acs.muohio.edu (Bob Williams) writes: >In article , ctaylor@fox.nstn.ns.ca (Christian Taylor) writes: >> Could someone please send me some sample source code of a background only >> app in Pascal? (THINK Pascal actually). Everytime I try to make a >> program background only, the Mac crashes whenever I click in the >> Application menu! And yes, I've read the Tech Note from ftp.apple.com on >> BOAs. Thanks! >> I'm sorry this in in C, but I believe you can read it anyway. The projet type must be 'appe' for background application (NOT 'APPL'). In addition, set 'Only background' size option. Since 'appe' is only background application, don't call usual toolbox-init routines. You must not use WindowManager, Menu manager etc. The following example misses MyQUIT() routine, an apple-event handler, that you should be able to write yourself. That application waits quit-apple event forever, and it doesn't eat system time at all (-: //---------------------------------------------------------- void HandleEvents(void) { WaitNextEvent(highLevelEventMask,&Event,-1L,NULL); switch(Event.what) { case kHighLevelEvent:AEProcessAppleEvent(&Event);break; }} main() { MaxApplZone(); MoreMasters(); AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0); idletime=-1L; do HandleEvents(); while (!lopetus); } //------------------------------------------------------------------------ -- Miika Asunta asunta@convex.csc.fi Double Bass Player tel. +358-31-255 9461 Macintosh Programmer +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Sun, 13 Nov 1994 23:07:59 +1200 Organization: AucklandUniversity:ComputerScience:HMU In article <3a2sqr$pla@pobox.csc.fi>, asunta@convex.csc.FI (Miika Asunta) wrote: > void HandleEvents(void) > { > WaitNextEvent(highLevelEventMask,&Event,-1L,NULL); > switch(Event.what) { > case kHighLevelEvent:AEProcessAppleEvent(&Event);break; > }} > > > > main() > { > MaxApplZone(); > MoreMasters(); > > AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0); > > idletime=-1L; > > do HandleEvents(); > while (!lopetus); > } You really should do an: InitGraf(&qd.thePort); // Metrowerks C/C++ or InitGraf(&thePort); // Symantec C++ or InitGraf(@thePort); // THINK Pascal after the calls to MaxApplZone() and MoreMasters(). This sets up the A5 world necessary for WNE and context switching. Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 Async, therefore I am. - --------------------------------------------------------------------- +++++++++++++++++++++++++++ >From jbobier@cybernetics.net (Jason Bobier) Date: Mon, 14 Nov 1994 09:12:45 -0500 Organization: Prismatix Software Whoops... couple of problems with this... In article <3a2sqr$pla@pobox.csc.fi>, asunta@convex.csc.FI (Miika Asunta) wrote: > I'm sorry this in in C, but I believe you can read it anyway. > The projet type must be 'appe' for background application (NOT > 'APPL'). In addition, set 'Only background' size option. FBA's can have a type of 'APPL' and can be launched at anytime. If the type is 'appe' they will be put in the extensions folder and launched automatically at startup if dragged to the system folder. > main() > { > MaxApplZone(); > MoreMasters(); // Add the following InitGraf(@qd.thePort); > > AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0); > > idletime=-1L; > > do HandleEvents(); > while (!lopetus); > } Jason _____________________________________________________________________ Jason A. Bobier Prismatix Software Email: jbobier@cybernetics.net "Living is easy with eyes closed..." - The Beatles +++++++++++++++++++++++++++ >From jbobier@cybernetics.net (Jason Bobier) Date: Mon, 14 Nov 1994 09:26:44 -0500 Organization: Prismatix Software In article , jbobier@cybernetics.net (Jason Bobier) wrote: > Whoops... couple of problems with this... Whoops... Late night with Macsbug... > > main() > > { > > MaxApplZone(); > > MoreMasters(); > // What I said > // Add the following > InitGraf(@qd.thePort); // What I meant InitGraf(&qd.thePort); > > > > > AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0); > > > > idletime=-1L; > > > > do HandleEvents(); > > while (!lopetus); > > } Sorry, Jason _____________________________________________________________________ Jason A. Bobier Prismatix Software Email: jbobier@cybernetics.net "Living is easy with eyes closed..." - The Beatles +++++++++++++++++++++++++++ >From here@there (Somone) Date: 17 Nov 1994 01:10:52 GMT Organization: Large Fuzzy Room Here. The Rez code and the C code to make the simplest possbile FBA. I took all the comments out so it wouldn't take much space in a posting, if you need parts of this explained *please* do your research and pull an FBA sample off summex or somewhere. /* rez data */ resource 'SIZE' (-1) { reserved, acceptSuspendResumeEvents, reserved, canBackground, notMultiFinderAware, onlyBackground, dontGetFrontClicks, ignoreChildDiedEvents, not32BitCompatible, isHighLevelEventAware, localAndRemoteHLEvents, notStationeryAware, dontUseTextEditServices, reserved, reserved, reserved, 50000, 50000 }; /* C code */ #include #include #include #include #include struct AEinstalls { AEEventClass theClass; AEEventID theEvent; EventHandlerProcPtr theProc; }; typedef struct AEinstalls AEinstalls; Boolean gQuit = false; EventRecord ERecord; Boolean gHasAppleEvents; main() { InitGraf((Ptr)&qd.thePort); InitAEStuff(); while (gQuit == false) { WaitNextEvent(highLevelEventMask, &ERecord, 30, 0); if (ERecord.what == kHighLevelEvent) DoHighLevel(&ERecord); } } void InitAEStuff(void) { AEinstalls HandlersToInstall[] = { { kCoreEventClass, kAEOpenApplication, AEOpenHandler }, { kCoreEventClass, kAEOpenDocuments, AEOpenDocHandler }, { kCoreEventClass, kAEQuitApplication, AEQuitHandler }, { kCoreEventClass, kAEPrintDocuments, AEPrintHandler }, }; OSErr aevtErr = noErr; long aLong = 0; Boolean gHasAppleEvents = false; gHasAppleEvents = (Gestalt(gestaltAppleEventsAttr, &aLong) == noErr); if (gHasAppleEvents) { register qq; for (qq = 0; qq < ((sizeof(HandlersToInstall) / sizeof(AEinstalls))); qq++) { aevtErr = AEInstallEventHandler(HandlersToInstall[qq].theClass, HandlersToInstall[qq].theEvent, HandlersToInstall[qq].theProc, 0, false); if (aevtErr) { ExitToShell(); /* just fail, baby */ } } } else { ExitToShell(); } } void DoHighLevel(EventRecord *AERecord) { AEProcessAppleEvent(AERecord); } pascal OSErr AEOpenHandler(AppleEvent *messagein, AppleEvent *reply, long refIn) { #pragma unused (messagein,reply,refIn) return(noErr); } pascal OSErr AEOpenDocHandler(AppleEvent *messagein, AppleEvent *reply, long refIn) { #pragma unused (reply, refIn,messagein) return(errAEEventNotHandled); } pascal OSErr AEPrintHandler(AppleEvent *messagein, AppleEvent *reply, long refIn) { #pragma unused (reply,refIn,messagein) return(errAEEventNotHandled); } pascal OSErr AEQuitHandler(AppleEvent *messagein, AppleEvent *reply, long refIn) { #pragma unused (messagein,refIn,reply) gQuit = true; return(noErr); } --------------------------- >From euajgo@eua.ericsson.se (Joakim Grebeno) Subject: Call PostEvent() from a TimeMgr task! Date: 9 Nov 1994 15:38:47 GMT Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Hi! Would it actually be possible to do a PostEvent() from a task (interrupt) triggered by the TimeManager, or is it forbidden? I would like to: 1. Setup an action to be executed at a later stage i.e. using InsTime() passing it a pointer to a function called A. 2. When the timed action is due to be executed it passes the pointer to A to the main event loop using PostEvent() ['app1Evt']. 3. The main event loop receives the event 'app1Evt' and calls function A contained in the event. Would this actually be possible? Thanks Joakim -- A: Look! It's a blast-furnace! B: It's a tree branch! A: OK! I can see that now! +++++++++++++++++++++++++++ >From Glenn L. Austin Date: Thu, 10 Nov 1994 17:25:00 GMT Organization: Eugene FreeNet In article <39qqe7$mbp@euas20.eua.ericsson.se> Joakim Grebeno, euajgo@eua.ericsson.se writes: >Would it actually be possible to do a PostEvent() from a task >(interrupt) triggered by the TimeManager, or is it forbidden? PostEvent doesn't move memory, so as long as your time manager routine doesn't move memory (a big no-no), yes, you could post an event. // // Glenn L. Austin // Computer Wizard and Racing Car Driver // Internet: glenn_a@efn.org // +++++++++++++++++++++++++++ >From euajgo@eua.ericsson.se (Joakim Grebeno) Date: 11 Nov 1994 08:14:04 GMT Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Glenn L. Austin writes: >In article <39qqe7$mbp@euas20.eua.ericsson.se> Joakim Grebeno, >euajgo@eua.ericsson.se writes: >>Would it actually be possible to do a PostEvent() from a task >>(interrupt) triggered by the TimeManager, or is it forbidden? >PostEvent doesn't move memory, so as long as your time manager routine >doesn't move memory (a big no-no), yes, you could post an event. Thanks! That's one problem out of the way! Furthermore I suppose that I have to setup the my applications A5 world in the task before doing a PostEvent()? If this is the case I'm forced to pass two parameters to the TimeManager task i.e the current A5 *and* the pointer to the function I want to post to the main event loop. Could this really be done? Thanks Joakim -- A: Look! It's a blast-furnace! B: It's a tree branch! A: OK! I can see that now! +++++++++++++++++++++++++++ >From scouten@uiuc.edu (Eric Scouten) Date: Fri, 11 Nov 1994 10:01:38 -0600 Organization: University of Illinois [follow-ups redirected to comp.sys.mac.programmer.help] In article <39v94c$s7h@euas20.eua.ericsson.se>, euajgo@eua.ericsson.se (Joakim Grebeno) wrote: > Thanks! That's one problem out of the way! Furthermore I suppose that I > have to setup the my applications A5 world in the task before doing a > PostEvent()? > If this is the case I'm forced to pass two parameters to the TimeManager > task i.e the current A5 *and* the pointer to the function I want to post to > the main event loop. Could this really be done? Yes, this is very easy to do. Just extend the TMTask record. You can do something like this: struct MyTMTask { TMTask tm; long itsA5; long refCon; // whatever your other parameter was }; -es __________________________________________________________________________ Eric Scouten * MS Comp Sci '96, Univ of Illinois IMPORTANT NOTICE TO READERS: The entire physical universe, including this message, may one day collapse back into an infinitesimally small space. Should another universe subsequently re-emerge, the existence of this message cannot be guaranteed. -with apologies to Devine & Cohen (Absolute Zero Gravity) +++++++++++++++++++++++++++ >From reed@medicine.wustl.edu (Thomas Reed) Date: Thu, 10 Nov 1994 10:25:25 -0600 Organization: Washington University I dunno if calling PostEvent is legal or not in that case. However, it sounds like for what you need, a safer method might be to have your TM task set a certain global flag, which your main event loop constantly checks for. When you see the flag set, you call the function. I use just this method to draw a picture to the screen every 5 seconds in one of my programs, and it works quite nicely. -Thomas ===================================================== Thomas Reed Washington University reed@telesphere.wustl.edu Medical School reed@medicine.wustl.edu Saint Louis, MO - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== Opinions posted are not the opinions of Wash. U. +++++++++++++++++++++++++++ >From bdiamand@netcom.com (Ben Diamand) Date: Wed, 16 Nov 1994 04:04:16 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Joakim Grebeno (euajgo@eua.ericsson.se) wrote: : Hi! : Would it actually be possible to do a PostEvent() from a task : (interrupt) triggered by the TimeManager, or is it forbidden? : I would like to: : 1. Setup an action to be executed at a later stage i.e. using : InsTime() passing it a pointer to a function called A. : 2. When the timed action is due to be executed it passes the : pointer to A to the main event loop using PostEvent() ['app1Evt']. : 3. The main event loop receives the event 'app1Evt' and calls : function A contained in the event. : Would this actually be possible? While PostEvent doesn't move/purge memory, the MacOS is not necessarily re-entrant in this area(or almost any area)...In other words, for all you know, someone else was calling PostEvent whem the timer went off and was right in the middle of posting an event when you call PostEvent! This _could_ be really bad...I'd go for the flag/post scheme, where you flag a variable and then call PostEvent from within your main event loop... Ben Diamand bdiamand@netcom.com +++++++++++++++++++++++++++ >From greg@cosc.canterbury.ac.nz (Greg Ewing) Date: 17 Nov 1994 01:13:51 GMT Organization: University of Canterbury, Christchurch, New Zealand In article , bdiamand@netcom.com (Ben Diamand) writes: |> for all |> you know, someone else was calling PostEvent whem the timer went off |> and was right in the middle of posting an event when you call PostEvent! It must surely be possible to post events at interrupt time - else what do the mouse and keyboard interrupt handlers do? I suspect that PostEvent disables interrupts while it is manipulating the event queue, in which case it would be safe to call it at interrupt time. But this is only a *guess* - attempt it at your own risk! |> Ben Diamand |> bdiamand@netcom.com Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.| greg@cosc.canterbury.ac.nz +--------------------------------------+ +++++++++++++++++++++++++++ >From pchang@Xenon.Stanford.EDU (The Weasel) Date: 17 Nov 1994 19:46:35 GMT Organization: Computer Science Department, Stanford University. In article <3aeaof$brg@cantua.canterbury.ac.nz>, Greg Ewing wrote: >In article , bdiamand@netcom.com (Ben Diamand) writes: >|> for all >|> you know, someone else was calling PostEvent whem the timer went off >|> and was right in the middle of posting an event when you call PostEvent! > >It must surely be possible to post events at interrupt >time - else what do the mouse and keyboard interrupt >handlers do? It is possible to do. Check out PPostEvent. What you get back is the eventqueue element, dequeue and enqueue turn off interrupts when playing with the queues. I'm pretty sure that PostEvent is just doing the same thing. However, consider what event queue you are going to be slamming this event into. I sort of missed the start of this discussion so I'm not sure why you are putting the events in the queue, but you really need to check to make sure which app is frontmost at the time as it is that apps eventqueue that is going to be mucked with. Peter +++++++++++++++++++++++++++ >From bdiamand@netcom.com (Ben Diamand) Date: Wed, 16 Nov 1994 04:04:16 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Joakim Grebeno (euajgo@eua.ericsson.se) wrote: : Hi! : Would it actually be possible to do a PostEvent() from a task : (interrupt) triggered by the TimeManager, or is it forbidden? : I would like to: : 1. Setup an action to be executed at a later stage i.e. using : InsTime() passing it a pointer to a function called A. : 2. When the timed action is due to be executed it passes the : pointer to A to the main event loop using PostEvent() ['app1Evt']. : 3. The main event loop receives the event 'app1Evt' and calls : function A contained in the event. : Would this actually be possible? While PostEvent doesn't move/purge memory, the MacOS is not necessarily re-entrant in this area(or almost any area)...In other words, for all you know, someone else was calling PostEvent whem the timer went off and was right in the middle of posting an event when you call PostEvent! This _could_ be really bad...I'd go for the flag/post scheme, where you flag a variable and then call PostEvent from within your main event loop... Ben Diamand bdiamand@netcom.com +++++++++++++++++++++++++++ >From bdiamand@netcom.com (Ben Diamand) Date: Wed, 16 Nov 1994 04:04:16 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Joakim Grebeno (euajgo@eua.ericsson.se) wrote: : Hi! : Would it actually be possible to do a PostEvent() from a task : (interrupt) triggered by the TimeManager, or is it forbidden? : I would like to: : 1. Setup an action to be executed at a later stage i.e. using : InsTime() passing it a pointer to a function called A. : 2. When the timed action is due to be executed it passes the : pointer to A to the main event loop using PostEvent() ['app1Evt']. : 3. The main event loop receives the event 'app1Evt' and calls : function A contained in the event. : Would this actually be possible? While PostEvent doesn't move/purge memory, the MacOS is not necessarily re-entrant in this area(or almost any area)...In other words, for all you know, someone else was calling PostEvent whem the timer went off and was right in the middle of posting an event when you call PostEvent! This _could_ be really bad...I'd go for the flag/post scheme, where you flag a variable and then call PostEvent from within your main event loop... Ben Diamand bdiamand@netcom.com +++++++++++++++++++++++++++ >From greg@cosc.canterbury.ac.nz (Greg Ewing) Date: 17 Nov 1994 01:13:51 GMT Organization: University of Canterbury, Christchurch, New Zealand In article , bdiamand@netcom.com (Ben Diamand) writes: |> for all |> you know, someone else was calling PostEvent whem the timer went off |> and was right in the middle of posting an event when you call PostEvent! It must surely be possible to post events at interrupt time - else what do the mouse and keyboard interrupt handlers do? I suspect that PostEvent disables interrupts while it is manipulating the event queue, in which case it would be safe to call it at interrupt time. But this is only a *guess* - attempt it at your own risk! |> Ben Diamand |> bdiamand@netcom.com Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.| greg@cosc.canterbury.ac.nz +--------------------------------------+ +++++++++++++++++++++++++++ >From pchang@Xenon.Stanford.EDU (The Weasel) Date: 17 Nov 1994 19:46:35 GMT Organization: Computer Science Department, Stanford University. In article <3aeaof$brg@cantua.canterbury.ac.nz>, Greg Ewing wrote: >In article , bdiamand@netcom.com (Ben Diamand) writes: >|> for all >|> you know, someone else was calling PostEvent whem the timer went off >|> and was right in the middle of posting an event when you call PostEvent! > >It must surely be possible to post events at interrupt >time - else what do the mouse and keyboard interrupt >handlers do? It is possible to do. Check out PPostEvent. What you get back is the eventqueue element, dequeue and enqueue turn off interrupts when playing with the queues. I'm pretty sure that PostEvent is just doing the same thing. However, consider what event queue you are going to be slamming this event into. I sort of missed the start of this discussion so I'm not sure why you are putting the events in the queue, but you really need to check to make sure which app is frontmost at the time as it is that apps eventqueue that is going to be mucked with. Peter +++++++++++++++++++++++++++ >From gspnx@di.unito.it (Fabrizio Oddone) Date: Thu, 17 Nov 1994 15:42:41 +0100 Organization: Politecnico di Torino - Italy In article , bdiamand@netcom.com (Ben Diamand) wrote: > Joakim Grebeno (euajgo@eua.ericsson.se) wrote: > : I would like to: > > : 1. Setup an action to be executed at a later stage i.e. using > : InsTime() passing it a pointer to a function called A. > > : 2. When the timed action is due to be executed it passes the > : pointer to A to the main event loop using PostEvent() ['app1Evt']. > > : 3. The main event loop receives the event 'app1Evt' and calls > : function A contained in the event. Also, PostEvent() posts the event to the frontmost application, not necessarily to your app, because there is a single event queue for all the running apps. So forget the appXEvt stuff and take a look at the Notification Manager... -- Fabrizio Oddone gspnx@di.unito.it --------------------------- >From Travis Peckham Subject: OSACompile and OSAExecute Date: Thu, 17 Nov 1994 17:01:45 GMT Organization: EMBA Computer Facility, University of Vermont Hi All, I was reading the comp.sys.mac.programmer FAQ (trying to get up to speed on AppleEvents and AppleScript) I found this: >5.2) Q:Can I compile and run scripts from my application? >A: Yes, this is very simple. There are toolbox calls for reading >scripts, compiling scripts and executing scripts. (OSACompile, >OSAExecute)... Does anyone know of some example source code which uses these calls to compile and execute an AppleScript? I'd be greatful. Thanks! Travis +++++++++++++++++++++++++++ >From jeremy@dewey.soe.berkeley.edu (Jeremy Roschelle) Date: Fri, 18 Nov 1994 09:42:05 -0800 Organization: SimCalc Project In article <1994Nov17.170145.5835@emba.uvm.edu>, Travis Peckham wrote: > Does anyone know of some example source code which uses these calls > to compile and execute an AppleScript? I'd be greatful. > here are two snippets (CodeWarrior C++) that should get you started: OSErr SCScriptEditor::CompileScript() { OSErr err; AEDesc scriptText = {typeChar,nil}; // get the text we want to compile scriptText.dataHandle = mTextEdit->GetTextHandle(); err = ::OSACompile(GetScriptingComponent(), &scriptText, kOSAModeNull, &mScriptID); mCompiledOK = (err == noErr); return err; } // this executes a script that was previously loaded (with the resulting ID) void ExecuteScript(ComponentInstance inScriptingComponent, OSAID inScriptID) { OSAID resultID; OSAExecute(inScriptingComponent,inScriptID,kOSANullScript,kOSAModeNull,&resultID); OSADispose(inScriptingComponent,resultID); } The first snippet stores the script ID in the member variable mScriptID. You would pass this ID to the Execute function. // this will get you a scripting component: scriptingComponent = OpenDefaultComponent(kOSAComponentType,'scpt'); good luck, Jeremy Roschelle [-------*--------] SimCalc Project [------*-*-------] 4104 24th Street #344 [-------*--------] San Francisco CA 94114 +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 18 Nov 1994 22:02:16 GMT Organization: Apple Computer Travis Peckham, travis@mirna.together.uvm.edu writes: > Does anyone know of some example source code which uses these calls > to compile and execute an AppleScript? I'd be greatful. There's a good article by Paul Smith in a recent issue of 'develop' (17?) that illustrates this and much more. I don't know the exact issue number offhand, but each one includes all the back issues on CD-ROM so you can find it if you get the latest issue. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" --------------------------- >From ttyab@vaal.cpr.upenn.edu () Subject: PBCatSearch finder flags? Date: 8 Nov 1994 21:12:16 GMT Organization: University of Pennsylvania Hi, I am trying to use PBCatSearch to search for files and EXCLUDE alias files. The search is already working with the ioNamePtr and ioFlAttrib flags and I would like to add whatever it takes to make the search exclude aliases. If a file is an alias, then ioFlFndrInfo.fdFlags will have bit 15 set (0x8000). Ok, well, in the CInfoPBRec search1 do I set ioFlFndrInfo.fdFlags = 0x0FFF??? (I don't care what the other 14 bits are) and then set search2 to 0xF000? (Search2 is "the mask"). Basically I don't know how to set the target and mask to include files with bit 15 == 0. Can some kind soul offer a solution? THanks! . +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 17 Nov 1994 03:10:07 -0500 Organization: America Online, Inc. (1-800-827-6364) In article <39opjg$bfm@netnews.upenn.edu>, ttyab@vaal.cpr.upenn.edu () writes: >Basically I don't know how to set the target and mask to include files >with bit 15 == 0. Can some kind soul offer a solution? This will do it for you. /* find files with alias bit clear */ searchInfo1.hFileInfo.ioFlFndrInfo.fdFlags = 0x0000; /* match when alias bit is clear */ searchInfo2.hFileInfo.ioFlFndrInfo.fdFlags = 0x8000; /* we're interested only in the alias bit */ Make sure you clear out the rest of the finder info record in both searchInfo1 and searchInfo2, and set the fsSBFlFndrInfo search bit. - Jim Luther --------------------------- >From gg110@cus.cam.ac.uk (G. Gavazzi) Subject: Q: SICompletionUPP Date: 16 Nov 1994 01:30:09 GMT Organization: University of Cambridge, England hi, I am trying to make an asynchronous sound recording (to memory) and I cannot figure out how to pass the address of my completionRoutine (and interruptRoutine as well). My program keeps on crashing when it calls SPBRecord(myinParamPtr,TRUE) since I put in myinParamPtr the routines addresses. I use: SICompletionUPP mycompletionRoutine(SPBPtr); SIInterruptUPP myinterruptRoutine(void); main(){ SICompletionUPP mycompletionRoutine(SPBPtr); SIInterruptUPP myinterruptRoutine(void); ... myinParam.completionRoutine = (SICompletionUPP)mycompletionRoutine; myinParam.interruptRoutine = (SIInterruptUPP)myinterruptRoutine; } SICompletionUPP mycompletionRoutine(SPBPtr inParamPtr) { operations on a buffer whose pointer is passed in myinParamPtr->userLong no return value } SIInterruptUPP myinterruptRoutine(void){} I don't need to do anything when the input device is full, I could indeed put myinParam.interruptRoutine = 0; above. If I put both routines fields in myinParam = 0 my program does not crash, it simply does not know when it's buffer is full of data. Can anybody point me to the (C please) solution? (yes, I am going to buy NIM on CD if it is affordable). Thank you, Giuliano Gavazzi +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Thu, 17 Nov 1994 00:40:45 +1200 Organization: AucklandUniversity:ComputerScience:HMU In article <3abnb1$83j@lyra.csx.cam.ac.uk>, gg110@cus.cam.ac.uk (G. Gavazzi) wrote: > I am trying to make an asynchronous sound recording (to memory) > and I cannot figure out how to pass the address of my completionRoutine > (and interruptRoutine as well). My program keeps on crashing when > it calls SPBRecord(myinParamPtr,TRUE) since I put in myinParamPtr > the routines addresses. > I use: > SICompletionUPP mycompletionRoutine(SPBPtr); > SIInterruptUPP myinterruptRoutine(void); > main(){ > SICompletionUPP mycompletionRoutine(SPBPtr); > SIInterruptUPP myinterruptRoutine(void); > ... > myinParam.completionRoutine = (SICompletionUPP)mycompletionRoutine; > myinParam.interruptRoutine = (SIInterruptUPP)myinterruptRoutine; > > } > SICompletionUPP mycompletionRoutine(SPBPtr inParamPtr) > { > operations on a buffer whose pointer is passed in myinParamPtr->userLong > no return value > } > SIInterruptUPP myinterruptRoutine(void){} > I don't need to do anything when the input device is full, I could indeed > put myinParam.interruptRoutine = 0; above. > > If I put both routines fields in myinParam = 0 my program does not > crash, it simply does not know when it's buffer is full of data. Here's some code I whipped up the other day to do almost exactly this: The #pragma parameter bit was necessary to tell the 68K compiler where the parameters are stashed on entry in 68K mode. /////////////////////////////////////////////////////////////////////////////// // Chris Burns 1994 /////////////////////////////////////////////////////////////////////////////// #include static Boolean FailOSErr(OSErr ErrNum,Str255 ErrMsgStr); static pascal void MyInterruptProc (SPBPtr PB,Ptr DataBuffer,short PeakAmplitude,long SampleSize); /////////////////////////////////////////////////////////////////////////////// static Boolean FailOSErr(OSErr ErrNum,Str255 ErrMsgStr) { if (ErrNum != noErr) { Str255 ErrStr; short ErrMsgBytes; short Extra; NumToString(ErrNum,ErrStr); ErrMsgBytes = ErrMsgStr[0]; Extra = 0; if ((ErrMsgBytes + 1 + ErrStr[0] + 1) > 255) { ErrMsgBytes = 255 - (2 + ErrStr[0] + 1); ErrStr[1 + ErrStr[0] + 1] = 'Š'; Extra = 1; } BlockMove(&ErrStr[1],&ErrStr[1 + ErrMsgBytes + Extra + 1],ErrStr[0]); BlockMove(&ErrMsgStr[1],&ErrStr[1],ErrMsgBytes); ErrStr[ErrMsgBytes + 1 + Extra] = '['; ErrStr[ErrMsgBytes + Extra + 1 + ErrStr[0] + 1] = ']'; ErrStr[0] = ErrMsgBytes + Extra + 1 + ErrStr[0] + 1; DebugStr(ErrStr); return(true); } return(false); } /////////////////////////////////////////////////////////////////////////////// #if !USESROUTINEDESCRIPTORS #pragma parameter MyInterruptProc(__A0,__A1,__D0,__D1) #endif static pascal void MyInterruptProc (SPBPtr PB,Ptr DataBuffer,short PeakAmplitude,long SampleSize) { #if !USESROUTINEDESCRIPTORS long SavedA5 = SetA5((*PB).userLong); #endif #if !USESROUTINEDESCRIPTORS SetA5(SavedA5); #endif } /////////////////////////////////////////////////////////////////////////////// void main (void) { OSErr Err; long SIRefNum; UniversalProcPtr MyInterruptProcUPP = NewSIInterruptProc(MyInterruptProc); SPB PB; Boolean Recording; Err = SPBOpenDevice("\p",siWritePermission,&SIRefNum); if (FailOSErr(Err,"\p FAILED")) { } // Set up recording parameters (rate, sample size, stereo etc) here PB.inRefNum = SIRefNum; PB.bufferPtr = nil; PB.completionRoutine = nil; PB.interruptRoutine = MyInterruptProcUPP; #if !USESROUTINEDESCRIPTORS PB.userLong = SetCurrentA5(); #endif Err = SPBRecord((SPBPtr)&PB,true); if (FailOSErr(Err,"\p FAILED")) { } Recording = true; while (Recording) { Recording = !Button(); } Err = SPBStopRecording(SIRefNum); if (FailOSErr(Err,"\p FAILED")) { } Err = SPBCloseDevice(SIRefNum); if (FailOSErr(Err,"\p FAILED")) { } #if USESROUTINEDESCRIPTORS DisposeRoutineDescriptor(MyInterruptProcUPP); #endif } /////////////////////////////////////////////////////////////////////////////// Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 Async, therefore I am. - --------------------------------------------------------------------- --------------------------- End of C.S.M.P. Digest **********************