Re: Problem with application hiding and revealing
Re: Problem with application hiding and revealing
- Subject: Re: Problem with application hiding and revealing
- From: Bill Monk <email@hidden>
- Date: Fri, 7 Oct 2005 11:43:21 -0600
When processing files, the app is very slow to respond to "Hide
Other" application command sent by other applications. Revealing
the app is also very sluggish.
One strong possibility for that is that NSAppleEvent
executeAppleEvent: is not only slow (presumably is must do an
osacompile for every script sent), it is also synchronous and doesn't
return control to the app until the script finishes.
Since Applescripts are just a bunch of Apple events, you can get much
better performance by building the AEs yourself and using AESend. But
that way lies madness - a line or two of Applescript may expand into
a page or two of ugly sequences of AECreateDesc(), AEPutParamPtr(),
and AECreateObjectSpecifier(). Also the Carbon frameworks are required.
Luckily, there's a third way: AEBuildAppleEvent() and AESendMessage
(), which live in ApplicationServices.framework and provide a printf
()-like way of building AEs. Some will remember them as part of the
old AEGizmos package. This approach takes less code than
NSAppleEvent, and is faster because 1) the messages are essentially
already "compiled" since they consist of the raw AEs 2) it's
asyncronous - you can send out hundreds of messages in the time it
takes NSAppleEvent to send one and return control to you.
This is great for telling some app to do a bunch of things when you
don't care what order it does them in, and don't want a reply back.
If you do want a reply from each message, AESendMessage() can be told
to put the replies into your event queue.
If a loop sends hundreds of Applescripts, they have to each be
compiled, sent, and then return before the app can get back to its
main event loop. With AEBuildAppleEvent()/AESendMessage(), the app
can blast them out and immediately go back to idling and waiting for
events, such as being switched in and out of the foreground or
receiving replies from AEs it sent.
The technique isn't perfect, because the syntax of the printf-like
format strings is under-documented and difficult to figure out for
complex AEs/scripts. It usually takes some trial and error, looking
at the compiled version of your Applescripts, to get it right. But
once done, it works great and is very powerful.
I have a sample app which demonstrates this by telling another app to
speak a phrase using each voice installed on the system. With
NSApplescript, the phrases dribble out one at a time, and the app is
locked in a loop until all are spoken. With AEBuildAppleEvent()/
AESendMessage(), there is a brief cacophony of voices as they all
speak at once. It also demonstrates vAEBuildAppleEvent(), the varargs
version of AEBuildAppleEvent() which can be vary handy.
In case it's useful, I'll clean the app up a little and post it later
today to
http://homepage.mac.com/tamarat/billmonk/cocoaexamples/
References:
"Two Approaches to Building an Apple Event" here (long url; may wrap)
http://developer.apple.com/documentation/AppleScript/Conceptual/
AppleEvents/index.html#//apple_ref/doc/uid/TP40001449
Apple TN2045
http://developer.apple.com/technotes/tn/tn2045.html
"AEGizmo, AEBuildAppleEvent and Mac OS X 10.4"
http://wincent.com/a/about/wincent/weblog/archives/2005/05/
aegizmo_aebuild.php
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden