Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.system
Subject: Re: AppleEvents Confusion...
Message-ID: <9496@goofy.Apple.COM>
Date: 31 Jul 90 01:24:59 GMT
References: <395@three.MV.COM>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 77

In article <395@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes:
> I have read the docs in IM VI and the New Apple Events Chapter,
> and I am still a bit confused about how to set up an application
> with AppleEvents.  Especially after reading the article about 
> User Agents (really a bad name for what they are... consider, 
> the normal use of an agent: they take 10% off of the top, and 
> do not really do much of anything.)

Heh, heh... I _love_ this one!

> Anyway, say I am building an application.  To reasonably enable 
> voice control and "Agents", I need to have all of the controlable
> units accessable via Appleevents.  How does this hypothetical 
> Agent know which events do what?

I'm not sure where the concept of "agents" enters into this.  You don't 
have to attempt to implement agents in order to take advantage of 
AppleEvents.

> How do I know what events to assign to which actions?

Ultimately there will be a widely-publicly-available document called the 
"AppleEvents Registry" which will be kept up-to-date with all of the 
existing standard AppleEvents, their parameters, semantics, sample code, 
etc.  If your application supports the semantics, then it should also 
support the standard AppleEvent.  If you have semantics that aren't 
covered but seem to need an AppleEvent (especially if the semantics are 
invoked as the direct consequence of a particular user action), then you 
should consider submitting a proposal for a new AppleEvent to the 
appropriate organization.  (The details of this organization and the 
process by which someone defines AppleEvents are very nearly worked out.  
Stay tuned.)

> What if my application needs more data to do something than another 
similar application?

That's one of the reasons that AppleEvents support optional parameters.

> or different data?

Again, you might have to play some semantic games, or use a completely 
different AppleEvent.  Try not to worry too much--it's not like you won't 
be able to roll your own and register them (or not, depending).

> For that matter, what is the advantage of using the event dispatch 
system call?

As opposed to what?  In answer to the question, the advantages are: being 
able to take advantage of AppleEvent recording/playback mechanisms, and 
ultimately to support AppleScript.

> Is it planned to do something other than just be an additional step 
between application modules?

See the above.

> Should I use it for internal communication?  *CAN* I use it for internal 
communication
> without a significant overhead?


Yes and yes.

You should for the reasons mentioned above--recording and scripting.  And 
no; the overhead won't kill you.  The case of sending to yourself is being 
heavily optimized (read: you won't even hit the network).

__________________________________________________________________________
                                Paul Snively
                      Macintosh Developer Technical Support
                             Apple Computer, Inc.

chewy@apple.com

Just because I work for Apple Computer, Inc. doesn't mean that I believe 
what they believe, or vice-versa.
__________________________________________________________________________