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? Jim Ault Las Vegas
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 more).
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 more reliable.
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.
Jesse _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
