Re: detecting when an app is beach-balling
Re: detecting when an app is beach-balling
- Subject: Re: detecting when an app is beach-balling
- From: has <email@hidden>
- Date: Mon, 22 Oct 2007 18:01:07 +0100
Martin Redington wrote:
yep, that wil send a misc/actv event to the app, and activate it
miscactv (activate) = bring to front, so you don't really want to use
that.
(starting it if its not started already, or bringing it to the front
otherwise).
Note that application launching is unrelated to Apple events. The
Apple Event Manager is not able to launch applications itself.
AppleScript automatically launches a non-running application by
calling the Carbon Process Manager's LaunchApplication() (there's
also LaunchServices' LSLaunchApplication() in 10.4+).
ascr/gdte seems to do what I want for running apps, but not for non-
scriptable apps (I'm presuming that I'll only be polling running
apps).
'ascrgdte' = 'get dynamic AppleScript terminology'. It will work for
any application as the OS provides a default ascrgdte event handler
that calls through to OSAGetAppTerminology. If an application doesn't
have a terminology resource, the reply event will contain a 'resource
not found' error (-192).
Ron Fleckner wrote:
-- begin AppleScript
[...]
-- end AppleScript
will start up any app, whether it's scriptable or not. Of course,
you have to name your target app properly, that is, substitute a
real name for "AnyApplication".
Those would be two pretty good reasons to avoid using the AppleScript
language. You probably don't want the application being launched
automatically if it isn't already running, and you definitely don't
want one of those wretched 'Where is application...?' dialogs
appearing if AppleScript can't immediately locate the application in
question. A third reason would be if you wanted to perform this test
from a non-main thread, for which AppleScript is teh suck.
Anyway, the standard 'no-op' event is ascrnoop. The AppleScript
equivalent is 'tell app "Foo" to launch', with the caveat that
AppleScript treats this command as a special case and always sends it
with a kAENoReply flag. That's no good if you're wanting to wait for
a reply event, but it's a non-issue if you send the event via another
method.
Assuming you don't tell the Apple Event Manager to wait forever for a
reply event (you can specify the timeout delay when you send the
event), what you're looking for is an 'event timed out' error (-1712)
returned by AESend()/AESendMessage() to tell you if the application
(specifically its main thread) is busy, or 'no error' (0) to tell you
that the event was received and responded to (you'll also get a reply
event containing an 'event not recognised' error, -1708, which you
can just ignore).
To build and send your event, you could use objc-appscript's AEM API
(which provides a convenient ObjC wrapper around the Apple Event
Manager API) to send the relevant event, or it's a simple enough task
that you could do pack and send the event yourself using
NSAppleEventDescriptor and AESendMessage. If you need example code,
just ask.
HTH (and touch-wood I got that all correct...)
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden