From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-008 Date: Sun, 3 Apr 94 22:39:07 MET DST C.S.M.P. Digest Sun, 03 Apr 94 Volume 3 : Issue 8 Today's Topics: ?Time manager code for pascal! Copying with a mask Macsbug for PowerMac? Math on PowerMacs (was Re: PowerMac emulate a 68LC040??) Passing data through to completion procs? Sending AppleEvents To Eudora 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 as comp.sys.mac.programmer.src. ------------------------------------------------------- >From dln2@cornell.edu (David Negro) Subject: ?Time manager code for pascal! Date: 18 Mar 1994 08:40:11 GMT Organization: Cornell University Hi, I was wondering if any of you had any code that I could take a quick look at on the time manager. I have the NIM Processes and have tried following the examples but with no luck whatsoever. It seems that when I run my test program to try to learn the time manager, that the program runs, seems to install the task, and then when it comes time for the task to execute it CRASHES ;-( When I pass a nil pointer for the task it seems to work fine as far as I can tell. But when I pass a pointer to a procedure (even one with nothing in it!) it seems to crash. I would post what is probably a pitiful piece of code for some of you to take a look, but at the moment I am so frustrated with having my sytem crash so many times that I don't want to look at it myself. So if anybody out there can just send me a snippet on how to install a task with instime and primetime I would greatly appreciate it! Thanks in advance, Dave Negro dln2@cornell.edu +++++++++++++++++++++++++++ >From zhfzc@zh014.ubs.ubs.ch (Christian Franz) Date: Fri, 18 Mar 1994 11:17:27 GMT Organization: Union Bank Switzerland, CH In article 180394033426@j30265153.reslife.cornell.edu, dln2@cornell.edu (David Negro) writes: >Hi, >I was wondering if any of you had any code that I could take a quick look >at on the time manager. I have the NIM Processes and have tried following >the examples but with no luck whatsoever. It seems that when I run my test >program to try to learn the time manager, that the program runs, seems to >install the task, and then when it comes time for the task to execute it >CRASHES ;-( >When I pass a nil pointer for the task it seems to work fine as far as I >can tell. But when I pass a pointer to a procedure (even one with nothing >in it!) it seems to crash. I would post what is probably a pitiful piece >of code for some of you to take a look, but at the moment I am so >frustrated with having my sytem crash so many times that I don't want to >look at it myself. I wager you are using THINK Pascal and have turned debugging on. That's a no-no since the TM callback proc will be called during interrupt-time where you are not allowed to do anything that moves memory... TP's Debugger does. I've had the same problem and they went away when I switched debugging off for the callback procedure. The catch is of course that you can't debug your callback. So what I did was to set a 'TimedOut' boolean flag in the callback proc and nothing else. >From the main program I monitored the timedOut flag and did all processing the was required when it did. >So if anybody out there can just send me a snippet on >how to install a task with instime and primetime I would greatly appreciate >it! Try disabeling debugging. If it still doesn't work, I'll send you some code. > >Thanks in advance, >Dave Negro >dln2@cornell.edu Cheers, Christian -- Christian Franz * Union Bank Of Switzerland cfranz@home.malg.imp.com <- at home -> +1-261 26 96 +++++++++++++++++++++++++++ >From spector@bach.seattleu.edu (Mitchell S. Spector) Date: 19 Mar 1994 07:24:34 -0800 Organization: Seattle University, Seattle, Washington, U.S.A. In article <1994Mar18.111727.15370@zh014.ubs.ubs.ch>, Christian Franz wrote: >In article 180394033426@j30265153.reslife.cornell.edu, dln2@cornell.edu (David Negro) writes: >> [Time Manager crashes, even when the task is an empty procedure.] > >I wager you are using THINK Pascal and have turned debugging on. That's a >no-no since the TM callback proc will be called during interrupt-time where >you are not allowed to do anything that moves memory... TP's Debugger does. Yes. And, even with debugging off, if you are running your program in the Think Pascal environment (rather than as a stand-alone application), there may be a limit on how frequently you can have the Time Manager execute a task. This limit will depend on the speed of the computer you are using. You ought to be safe if you make sure that your period is at least 1/30 sec; I've been able to use the Time Manager with that period even on an old Mac II, but 1/60 sec didn't work. Or else build a stand-alone application -- you can then use any time interval you want. Also, be sure that you're setting and restoring A5; Inside Macintosh shows how to do this. Mitchell >>Dave Negro >>dln2@cornell.edu >Christian Franz * Union Bank Of Switzerland >cfranz@home.malg.imp.com <- at home -> +1-261 26 96 -- Mitchell Spector spector@seattleu.edu --------------------------- >From alex@metcalf.demon.co.uk (Alex Metcalf) Subject: Copying with a mask Date: Sun, 20 Mar 1994 13:27:27 GMT Organization: Demon Internet I'm looking for an efficient way to do a mask copy between offscreen graphics worlds. I have a solution which works, but it MUST be possible to do it faster! Here's the code (all variables are in registers, BTW): if (*tMaskMemPtr++) { *tDestMemPtr++ = *tSourceMemPtr++; } else { *tDestMemPtr++; *tSourceMemPtr++; } tMaskMemPtr, tDestMemPtr, and tSourceMemPtr are each pointers to chars to separate offscreen worlds (mask, destination, and source worlds, respectively). It's being done in 8-bit (so one byte/pixel), and the mask is either black or white. I'm checking the mask world pixel: if it's black, I'm copying the source pixel to the destination pixel; otherwise, I'm leaving the destination alone. I couldn't think of a way to do it using pointers to longs, but if there was a way it would be much faster! Anyone got any ideas? I'd prefer C code rather than assembler, but both are appreciated. Thanks, Alex -- Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler Internet, AOL, BIX: alex@metcalf.demon.co.uk "Surely you AppleLink: alex@metcalf.demon.co.uk@internet# can't be CompuServe: INTERNET:alex@metcalf.demon.co.uk serious?" Delphi: alex@metcalf.demon.co.uk@inet# FirstClass: alex@metcalf.demon.co.uk,Internet "I'm serious... Fax (UK): (0570) 45636 and don't call Fax (US / Canada): 011 44 570 45636 me Shirley." +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 20 Mar 94 16:54:42 GMT Organization: PowerTools, Austin, Texas In article alex@metcalf.demon.co.uk (Alex Metcalf) writes: > I'm looking for an efficient way to do a mask copy between offscreen >graphics worlds. I have a solution which works, but it MUST be possible to >do it faster! > Here's the code (all variables are in registers, BTW): >if (*tMaskMemPtr++) >{ > *tDestMemPtr++ = *tSourceMemPtr++; >} else >{ > *tDestMemPtr++; > *tSourceMemPtr++; >} > tMaskMemPtr, tDestMemPtr, and tSourceMemPtr are each pointers to chars >to separate offscreen worlds (mask, destination, and source worlds, >respectively). > It's being done in 8-bit (so one byte/pixel), and the mask is either >black or white. I'm checking the mask world pixel: if it's black, I'm >copying the source pixel to the destination pixel; otherwise, I'm leaving >the destination alone. > I couldn't think of a way to do it using pointers to longs, but if >there was a way it would be much faster! Anyone got any ideas? I'd prefer C >code rather than assembler, but both are appreciated. Well, this explanation will be more theoretical than practical, so I'm more likely to use assembly than C. To my knowledge, there are three ways to get "just the picture part" of a graphic overlaid into a background. One uses transparency, and two use masking. The first way is similar to what you are doing now. In fact, if you guarantee that the "transparent" parts of your image will have some specified value (for example, 0), you can forego the mask entirely: if (*tSourceMemPtr) *tDestMemPtr++ = *tSourceMemPtr++; else { tSourceMemPtr++; tDestMemPtr++; } The advantage of this approach is that it is memory-efficient. The disadvantage is that, as you have seen, it only works byte by byte. The only optimization I have found, in assembly, is to load the source a long word at a time and add 4 to the destination pointer if the result of the load is zero, thus avoiding the byte-by-byte check. The second (and fastest) approach also presumes that you control the source graphics, and that the parts of these graphics to be masked are set to zero. In this approach, the mask is all zeros where the source graphic is "on", and all ones in the "transparent" portions. Under these conditions, you can do a long word as follows: MOVE.L (destPtr), D0 ;get "background" AND.L (maskPtr)+, D0 ;keep only the part not covered by graphic OR.L (srcPtr)+, D0 ;add graphic MOVE.L D0, (destPtr)+ ;move to offscreen memory The third (and most general) approach presumes only that you can make a mask covering the portions of the graphic you wish to transfer. In this case, the mask is all ones for the parts of the source graphic you want to copy, and all zeros where you want the background to show through. In assembly, the transfer looks like this: MOVE.L (srcPtr)+, D0 ;Get long word of source EOR.L (destPtr), D0 ;D0 now XOR of source and dest AND.L (maskPtr)+, D0 ;Bkg part now all 0s EOR.L (destPtr), D0 ;Remove bkg bits from graphic while ;adding them to bkg part MOVE.L D0, (destPtr)+ ;move to offscreen memory Of course, all of these transfer operations can be done the same way in C. I just think the assembly notation makes them more clear. --Al Evans-- -- Al Evans Tu causes, tu causes al@crucible.powertools.com C'est tout ce que tu sais faire cs.utexas.edu!crucible!al -- LaVerdure --------------------------- >From johnsone@uxh.cso.uiuc.edu (Erik A. Johnson) Subject: Macsbug for PowerMac? Date: 17 Mar 1994 22:51:42 GMT Organization: University of Illinois at Urbana Anyone know if Apple has a debugger (a la Macsbug) for the PowerMacs, either in existence, in development, or planned? Erik A. Johnson \ Internet: johnsone@uxh.cso.uiuc.edu \ | - ----------------------\ AmericaOnline: ErikAJ \ --+-- Graduate Student \--------------------------------------------\ | Aero/Astro Engineering \ "Jesus said to him, 'I am the way, and \ | University of Illinois at \ the truth, and the life; no one comes to \ | Urbana-Champaign (UIUC) \ the Father except through me.'" (Jn14:6) \ +++++++++++++++++++++++++++ >From somogyi@macuser.ziff.com (Stephan Somogyi) Date: Fri, 18 Mar 1994 01:02:38 GMT Organization: MacUser Magazine US In article <2mamtu$lfe@vixen.cso.uiuc.edu>, johnsone@uxh.cso.uiuc.edu (Erik A. Johnson) wrote: > Anyone know if Apple has a debugger (a la Macsbug) for the PowerMacs, > either in existence, in development, or planned? Macsbug works just fine on my Power Mac :-) Apple has a 2-machine debugger for the Power Macs that once was called R2DB but now has a more whizzy and marketing-oriented name (Macintosh Debugger for PowerPC?). Metrowerks has a one-machine Power Mac debugger that comes with CodeWarrior. The current version of Jasik's Debugger also has a bunch of Power Mac support. __________________________________________________________________________ Stephan Somogyi "...we shall never surrender." MacUser +++++++++++++++++++++++++++ >From ajr3@quads.uchicago.edu (Alain Roy) Date: Fri, 18 Mar 1994 02:56:20 GMT Organization: University of Chicago In article <2mamtu$lfe@vixen.cso.uiuc.edu> johnsone@uxh.cso.uiuc.edu (Erik A. Johnson) writes: >Anyone know if Apple has a debugger (a la Macsbug) for the >PowerMacs, either in existence, in development, or planned? believe it or not, macsbug will run on the power mac. i've seen it. of course, 68K disassembly and stack crawls are meaningless, but it works! though it would be nice if they had "power macsbug" though could actually be useful for more than "es, rs and g" -alain +++++++++++++++++++++++++++ >From mlanett@netcom.com (Mark Lanett) Date: Fri, 18 Mar 1994 09:58:34 GMT Organization: Etch-a-Sketch Analysis and Design somogyi@macuser.ziff.com (Stephan Somogyi) writes: >In article <2mamtu$lfe@vixen.cso.uiuc.edu>, johnsone@uxh.cso.uiuc.edu >(Erik A. Johnson) wrote: >> Anyone know if Apple has a debugger (a la Macsbug) for the PowerMacs, >> either in existence, in development, or planned? >Macsbug works just fine on my Power Mac :-) The slight problem with Macsbug, as I understand it, is that it's being emulated (!) and all the 601 stuff is done through dcmds, which makes them harder to use. -- Mark Lanett "Have a bajillion brillian Jobsian lithium licks" +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Fri, 18 Mar 1994 16:58:10 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA somogyi@macuser.ziff.com (Stephan Somogyi) writes: > Apple has a 2-machine debugger for the Power Macs that once was > called R2DB but now has a more whizzy and marketing-oriented > name (Macintosh Debugger for PowerPC?). Yup. It's not bad, but it's sllllooooowwwwwww. What I wish I had is something like TMON. Not TMON Pro--the old small, fast TMON--but updated for PowerPC debugging. I don't even need source debugging if I can get fast stack crawls and breakpoints. Sigh. Amanda Walker Advanced Projects InterCon Systems Corporation +++++++++++++++++++++++++++ >From danprice@delphi.com Date: Sat, 19 Mar 94 00:37:37 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Ouch! Does Apple or Motorola plan to release a PPC debugger? Howbout TMON or Jasik Systems? Is there a PPC disassembler (like the old DisASM) yet? -dp --------------------------- >From rang@winternet.mpls.mn.us (Anton Rang) Subject: Math on PowerMacs (was Re: PowerMac emulate a 68LC040??) Date: 19 Mar 1994 16:44:25 GMT Organization: Minnesota Angsters In article grstate@zeus (Gavriel State) writes: >Extrapolating from this leads me to suspect that you might get as much >as an 8x speedup over 040/FPU code, or 20-25x improvement over your >IIci's 030/FPU. Last night I wrote up a simple FP benchmark and ran it on a Quadra 700 (25MHz 68040) and the 8100. I took a small (200x201) matrix and wrote up a quick Gaussian elimination by back-substitution routine. No optimizations, nothing fancy, just to get an idea of relative performance. (I didn't test with SANE; everything was done with the FPU.) Unfortunately the matrix would mostly fit in the L2 cache, so it's not a perfect way to compare performance on large arrays, but for what it's worth.... Times are in seconds. TC = THINK C 6.0.1, MPW = MPW 3.3, MW = Metrowerks 1.0a2, SDK = Apple's SDK (Lucid compiler). Float Double Q700/MPW: 14.57 15.07 Q700/TC: 5.13 7.47 8100/MW: 1.07 1.14 8100/SDK: 0.83 0.72 A few remarks -- MPW does very poorly because it doesn't strength-reduce the array indexing inside loops. I think it might do that when "-opt full" is on, but MPW C 3.3 wouldn't generate correct code for this test unless I used "-opt on" instead. THINK C does a much better job, applying strength-reduction to the loops, and thus eliminating almost all integer multiplication. The Metrowerks compiler doesn't do strength reduction (or at least, I couldn't get it to), but apparently the 601's integer multiply isn't as slow as that of the 68040. It wins on floating-point numbers, even though the 601 does all arithmetic internally in double precision. My guess is that this is because the FP array fits in the L2 cache. The SDK compiler does a good job of optimization. Not only does it do the basic strength reduction for the loops (and eliminate the now-unneeded induction variables), but it also unrolls the inner loop (though only in the single-precision case) and changes the operation inside the inner loop (a[i][j] <- a[i][j] - a[k][j]/F) into a multiply-negate-add instruction. So it looks like, even compared to a hypothetical 50MHz 68040 machine, you'd get better performance on the 8100. I didn't get a chance to try gcc or another highly optimizing compiler, but I doubt that it could perform more than a factor of two better on the '040, in the best case. I've added comp.sys.mac.programmer because of the compiler comparison; please followup to the appropriate group. -- Anton Rang (rang@winternet.mpls.mn.us) --------------------------- >From gewekean@studentg.msu.edu (Andrew Geweke) Subject: Passing data through to completion procs? Date: Wed, 16 Mar 1994 22:06:40 -0500 Organization: Michigan State University What I'm doing is writing an interface library to MacTCP; I want it to be simple. All routines are async, so I just want to have the caller pass in a simple structure pointer; a field in the struct gets changed when the call completes. I want to do this rather than having the user ravage through large ParamBlocks and so forth for simplicity and so on. My question is this: How can I get the Device Manager to pass four bytes to a completion routine that I pass in when I make the call? Basically, I'm having trouble getting a pointer to the structure through to the completion routine. Is there any place I can stash this? I'm looking through the ParamBlock structure right now, and everything's used or "not used" (which, as we all know, means reserved -- I don't want to break rules here). Here are my ideas so far: (1) Set the user up with a pointer to the ioResult field. Disadvantage: I want to deallocate the parameter-block's memory as soon as the call completes. This would require the user to do this. (2) Create a linked list of all outstanding calls with pointers to their parameter blocks. This is a roundabout method, though it should work; however, I'd rather not. Basically, I'm converting async calls from the beasts that they are into simple ones; you pass in a struct with only the specific information that gets a flag set when it's done. Any ideas? +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Thu, 17 Mar 1994 01:37:49 -0600 Organization: University of Illinois at Urbana-Champaign In article <9403162206.AA40375@geweke.ppp.msu.edu>, gewekean@studentg.msu.edu (Andrew Geweke) wrote: >What I'm doing is writing an interface library to MacTCP; > >My question is this: How can I get the Device Manager to pass four bytes to a >completion routine that I pass in when I make the call? > >Basically, I'm having trouble getting a pointer to the structure through to >the completion routine. Is there any place I can stash this? Since you're using MacTCP, you're in luck. Every MacTCP param block has a userDataPtr field, which is exactly where you can store any pointer you like. Even if this field weren't there, you can do the same thing. Just make your own personal parameter block which contains everything the real parameter block does, plus one pointer field tacked onto the end. The Device Manager and driver are only going to use the fields they specify, so this is perfectly safe. (How could it not be? It would be quite ugly if a device driver decided to use some memory past the end of its parameter block!) 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: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From zben@ni.umd.edu (Charles B. Cranston) Date: 18 Mar 1994 00:50:47 GMT Organization: UMCP Network Infrastructures In article <9403162206.AA40375@geweke.ppp.msu.edu>, gewekean@studentg.msu.edu (Andrew Geweke) wrote: > What I'm doing is writing an interface library to MacTCP; I want it to be > simple. All routines are async, so I just want to have the caller pass in a > simple structure pointer; a field in the struct gets changed when the call > completes. I want to do this rather than having the user ravage through large > ParamBlocks and so forth for simplicity and so on. > My question is this: How can I get the Device Manager to pass four bytes to a > completion routine that I pass in when I make the call? Another approach would be to erect a "trampoline" somewhere. This would be 8 bytes consisting of a JSr to the real handler followed by the four data bytes. The real handler immediately does a Move.L (A7)+,A0 and then A0 points to the four data bytes, and the stacktop is now the real final return address. For MacTCP the UserData approach or the embed-IOPB-in-larger-known-block approaches would both work. I am thinking about using this trampoline technique for EtherNet "Protocol Handlers" where the IOPB is not passed to the callback routine. The cost, of course, is allocating and freeing the memory space for the trampoline, especially in the asynchronous environment you are talking about. +++++++++++++++++++++++++++ >From markhanrek@aol.com (MarkHanrek) Date: 18 Mar 1994 12:52:03 -0500 Organization: America Online, Inc. (1-800-827-6364) A similar trick which works is to declare a data structure in which your custom info is first, and then you pass the address of the record field that is, say, four bytes from the actual beginning of the record structure to the asynchronous function. There are situations, such as with the Time Manager, in which you are able to get the address of the parameter block the completion routine is passing in by grabbing the value in register A0, and then subtracting four from it to get at the specisl data value you've stashed. It may be that this is "six of one - half-dozen of the other" with regard to Pete's excellent suggestion, but then maybe this is a uniform way of dealing with getting piggy-back data values that will work in every case regardless of the size of a given routine's parameter blocks. Hope this helps. Mark Hanrek +++++++++++++++++++++++++++ >From zben@ni.umd.edu (Charles B. Cranston) Date: 20 Mar 1994 18:41:43 GMT Organization: UMCP Network Infrastructures In article <2mcpo3$qva@search01.news.aol.com>, markhanrek@aol.com (MarkHanrek) wrote: > A similar trick which works is to declare a data structure in > which your custom info is first, and then you pass the address > of the record field that is, say, four bytes from the actual > beginning of the record structure to the asynchronous function. Yes, this is exactly the "embed-IOPB-in-larger-known-block" solution that I alluded to in the article you followed up. This works for the Time Manager, the Vertical Retrace Manager, and general IO. (Except maybe very early systems which don't pass the block in A0, I no longer remember the specifics.) This works when the system is maintaining TWO pieces of information for you: the control block (IOPB, Time Manager Block, etc) *AND* the address of the completion routine. When the system is only maintaining ONE piece of information for you (like the EtherNet driver's Protocol Handler, maybe also the LocalTalk driver's Protocol Handler) then the "trampoline" technique can be used to compress those two pieces of information (the REAL completion routine and the data value) into one (the trampoline's address). > It may be that this is "six of one - half-dozen of the other" with regard to > Pete's excellent suggestion, but then maybe this is a uniform way of dealing > with getting piggy-back data values that will work in every case regardless of > the size of a given routine's parameter blocks. Indeed, this is quite correct. Also, I blew it when I said 8 bytes of information. I believe the minimum would be 10 bytes: 2 byte absolute JSR opcode 4 byte absolute address of the REAL completion routine 4 byte data or pointer to data Typical dislexic problem. Also see my short tip in this month's MacTutor where I conclude that a 16 bit word has 16384 possible values (and not 65536). I'm suprised the editors didn't catch it. Er, ah, that's MacTech magazine. I'm so old I still say "Megacyles"... de KE3HE --------------------------- >From Laurent Humbert Subject: Sending AppleEvents To Eudora Date: Sun, 20 Mar 1994 12:02:23 GMT Organization: QED Technology Ltd Hi there, In the application I am writting, I would need to tell Eudora to create a new message window, with a given To and Subject fields, as well as an initial content. For the moment, I do just like Nuntius, bringing Eudora to the foreground, then calling PostEvent while I am in the background. Needless to say, this is a hack. I am no AppleEvent manager expert, so if somebody has already written a routine that looks like OSErr NewMessageInEudora( ProcessSerialNumber *eudoraPSN, Str255 to, Str255 subject, Handle initialcontent); then I would be very interested (this is for a shareware application I am working on). Thank you very much. Laurent o o \|||/ +----------------oOO-(o o)-OOo--------------+ | Laurent Humbert | | Internet : laurent@humbert.demon.co.uk | | AppleLink : UK2001 CI$ : 100270,1136 | +-------------------------------------------+ +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Sun, 20 Mar 1994 19:49:30 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Laurent Humbert (laurent@humbert.demon.co.uk) wrote: > In the application I am writting, I would need to tell > Eudora to create a new message window, with a given To and Subject > fields, as well as an initial content. I would consider using AppleScript's OSA layer to do this if you can get away with it. It results in more flexible code since you can run a variety of scripts with it, whereas your Eduroa routine will only do one thing. The 2 routines will be about the same complexity to write. Sorry I don't have details on your routine. Jon --------------------------- End of C.S.M.P. Digest **********************