jsng at wayoflife.org
Sat Dec 9 18:03:25 CST 2006
>I agree, AppleEvents are easier and faster than AppleScript.
>However, in my particular case, it was UDP I used.
>-1- I need both Win and Mac
>-2- the Rev 'do script' was broken until 2.7 When I was using 2.6 I could
>not be sure when this would be fixed and could not wait
>-3- the data service uses UDP to broadcast, not AppleEvents
>-4- low traffic rate for UDP is about 150 packets per second so that I do
>not have to worry about "not being able to receive fast enough", thus lost
>data is due to problems in my code
AppleEvents is managed by the OS and since it gets queued for you,
you never have to worry about not being able to receive fast enough.
Once your app is receive to process the next AE, it's there sitting
in the queue.
One advantage over the data file approach is that you don't have to
poll the file system regularly to see if there's something for you or
not. Granted it eventually gets cached, but you still need to hit the
file system (in memory) all the time.
With AE, you are now event driven and only need to respond when you
receive such an event. Otherwise, your app is just sitting pretty.
>It would be cool if you could make some useful example stacks that would
>show 3 apps using AppleEvents. I know Ken Ray has some good tips on his web
>site, which I have happily used.
>How would you use AppleEvents in your work flow?
In the past, I had 2 apps running on the system. This was an
interactive kiosk app plus a controller app. The controller app was
written in C++ and basically did most of the AE handling and the
kiosk app had some rudimentary AE capabilities.
I had a 3rd app (sysadmin's app) running from across the network that
would send AppleEvents to the remote machine's controller app. This
app could then shut down the kiosk app, while it puts up a full
screen that simply had a message saying that the system was currently
"under maintenance". It had the ability to then automatically
download the latest version of the kiosk app (signalled by the
sysadmin), update its local copy of the database and even reboot the
machine if need be. The controller app also did other things like
managed log files and it receives log data from the kiosk app to
track what users did on the system. I can't remember how the log
files were transmitted, but I think it was through AppleEvents across
the network to the sysadmin's app (it's been at least 8 years or
Once done, it would launch the kiosk app again. The kiosk app only
needs to understand the "quit" AE, which is standard on the Mac and
is sent everytime an app on OS X is required to quit itself.
So basically the sysadmin's app did most of the sending, the
controller app simply received AEs and responded and the kiosk app
mostly did what it was designed to do and in addition, responded to
the Quit AE and sent log data via AE to the controller app.
Given the bandwidth limitations that I had back then (19.2kbps leased
line modem connection bridging to a fibre network), it didn't make
sense to use something like Timbuktu and I found this approach far
All this worked very nicely considering that we were running on OS
8.x without the kind of multitasking kernel that we have on OS X.
My original inspiration for all this was the concept of remote
debuggers where data was exchanged between the app being debugged and
the debugger. I had hacked up a remote debugger for one of my server
apps so that I could monitor the status via AE and grab information
and this eventually morphed into the controller app that I used for
networked kiosk management.
More information about the use-livecode