ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-008

Text File | 2010-09-21 | 29KB | 762 lines

Received-Date: Sun, 3 Apr 1994 22:39:12 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-008
To: [e-mail]
Date: Sun, 3 Apr 94 22:39:07 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 10

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
([e-mail]).

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 [e-mail] 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 [e-mail]
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
[e-mail]. 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 [e-mail] (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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Christian Franz)
Date: Fri, 18 Mar 1994 11:17:27 GMT
Organization: Union Bank Switzerland, CH

In article [e-mail], [e-mail] (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
>[e-mail]

Cheers,
Christian


--
Christian Franz                        *              Union Bank Of Switzerland
[e-mail]         <- at home ->                     [phone]


+++++++++++++++++++++++++++

>From [e-mail] (Mitchell S. Spector)
Date: 19 Mar 1994 07:24:34 -0800
Organization: Seattle University, Seattle, Washington, U.S.A.

In article <[e-mail]>,
Christian Franz <[e-mail]> wrote:
 >In article [e-mail], [e-mail] (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
 >>[e-mail]

 >Christian Franz                        *              Union Bank Of Switzerland
 >[e-mail]         <- at home ->                     [phone]

--
Mitchell Spector
[e-mail]


---------------------------

>From [e-mail] (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: [e-mail]            "Surely you
AppleLink:          [e-mail]@internet#   can't be
CompuServe:         INTERNET:[e-mail]    serious?"
Delphi:             [e-mail]@inet#
FirstClass:         [e-mail],Internet   "I'm serious...
Fax (UK):           (0570) 45636                         and don't call
Fax (US / Canada):  011 44 570 45636                     me Shirley."

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 20 Mar 94 16:54:42 GMT
Organization: PowerTools, Austin, Texas

In article <[e-mail]> [e-mail] (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
[e-mail]               C'est tout ce que tu sais faire
cs.utexas.edu!crucible!al                     -- LaVerdure

---------------------------

>From [e-mail] (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: [e-mail]     \       |
- ----------------------\    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 [e-mail] (Stephan Somogyi)
Date: Fri, 18 Mar 1994 01:02:38 GMT
Organization: MacUser Magazine US

In article <2mamtu$[e-mail]>, [e-mail]
(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 [e-mail] (Alain Roy)
Date: Fri, 18 Mar 1994 02:56:20 GMT
Organization: University of Chicago

In article <2mamtu$[e-mail]> [e-mail] (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 [e-mail] (Mark Lanett)
Date: Fri, 18 Mar 1994 09:58:34 GMT
Organization: Etch-a-Sketch Analysis and Design

[e-mail] (Stephan Somogyi) writes:

>In article <2mamtu$[e-mail]>, [e-mail]
>(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 [e-mail] (Amanda Walker)
Date: Fri, 18 Mar 1994 16:58:10 -0500
Organization: InterCon Systems Corporation, Herndon, VA USA

[e-mail] (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 [e-mail]
Date: Sat, 19 Mar 94 00:37:37 -0500
Organization: Delphi ([e-mail] 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 [e-mail] (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 <[e-mail]> 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 ([e-mail])

---------------------------

>From [e-mail] (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 [e-mail] (Pete Resnick)
Date: Thu, 17 Mar 1994 01:37:49 -0600
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>,
[e-mail] (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: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Charles B. Cranston)
Date: 18 Mar 1994 00:50:47 GMT
Organization: UMCP Network Infrastructures

In article <[e-mail]>,
[e-mail] (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 [e-mail] (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 [e-mail] (Charles B. Cranston)
Date: 20 Mar 1994 18:41:43 GMT
Organization: UMCP Network Infrastructures

In article <2mcpo3$[e-mail]>,
[e-mail] (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 <[e-mail]>
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  : [e-mail] |
|   AppleLink : UK2001    CI$ : 100270,1136 |
+-------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Sun, 20 Mar 1994 19:49:30 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Laurent Humbert ([e-mail]) 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
**********************