RE: accessing a property of an object in AppleScript
RE: accessing a property of an object in AppleScript
- Subject: RE: accessing a property of an object in AppleScript
- From: Scott Babcock <email@hidden>
- Date: Mon, 10 Nov 2008 13:54:29 -0800
- Acceptlanguage: en-US
- Thread-topic: accessing a property of an object in AppleScript
The problem here is most likely one of nesting. The term "name" is a part of base AppleScript terminology, so it will compile to the same Apple Event code outside of a System Events "tell" block as it does inside. However, "enabled" is a term that's specific to System Events. It doesn't appear in base terminology, so "enabled" will be interpreted as a variable name when it's encountered outside of a System Events "tell" block. A UI element has no property whose key is "enabled"; this is merely the human-readable representation of the underlying application-specific Apple Event code 'enaB', and a variable named "enabled" does not equate to Apple Event code 'enaB'.
When you get the properties of an object, you get an AppleScript record which is essentially a snapshot of the object. The record - a collection of key/value pairs - has keys and values that include application-specific identifiers. In order to access entries in the record, you need to supply the correct Apple Event codes as the keys. This can either be accomplished by performing the operation within the context of a "tell" block (letting AppleScript do the work for you) or by scripting the keys as raw Apple Event codes. In the example you're working on:
set isEnabled to (<<class enaB>> of (properties of myElement)) -- get [enabled] property
NOTE: The "<<" and ">>" are actually angle-quote characters. Use the <option-\> and <options-shift-\> key chords to generate these.
By the way, you shouldn't really need to use the [properties] property unless you plan to hand this object snapshot record around for some sort of extraordinary processing. You should just be able to access each property directly:
set isEnabled to (<<class enaB>> of myElement)
OR
tell application "System Events" to set isEnabled to (enabled of myElement)
OR
tell application "System Events"
set isEnabled to (enabled of myElement)
end tell
-----Original Message-----
Date: Fri, 7 Nov 2008 10:11:11 -0500
From: "Mark J. Reed" <email@hidden>
Subject: Re: accessing a property of an object in AppleScript
To: "Mark Sanvitale" <email@hidden>
Cc: Stan Cleveland <email@hidden>,
email@hidden
Message-ID:
<email@hidden>
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 7, 2008 at 3:00 AM, Mark Sanvitale <email@hidden> wrote:
> I have a variable/object that is a menu item. I can see it has all of these
> properties. But I cannot ask it anything about its properties (even though
> I can see they are all there) unless I do so within the tell block of the
> application whose dictionary defines the type of object I am attempting to
> query (whereas I naturally looked upon the object/variable as an
> encapsulated, fully-functional thing that I could operate on through the
> script). Maybe that is the explanation?
Indeed. When you get an object from an application, most of the
operations available on that object must be performed by the
application. You have some limited access to see into the object
using AppleScript primitives, but that's it. The "get" operator will
do as much as it can to fully dereference an application object - so
that instead of something that means "the third item of this list over
here", you get the actual value of that third list item - but if the
value is of an application-specific class, you still can't do much
with it outside of a tell block to the application.
I like to think of Applescript programs as web clients, with the
application in the role of the web server, and the values you get back
from the app as cookies. Sometimes you can look at the cookie value
and discern meaningful information directly; for instance, I have a
"last5stocks" cookie from cnn.com, and its value is a simple text list
of the last 5 ticker symbols I looked up via money.cnn.com. But many
times the value is meaningless outside the context of server-side
data; for that same domain I have two flavors of "user id" cookie
whose values are long strings of letters and digits that presumably
serve as nothing but indexes into some database I can't access
directly.
--
Mark J. Reed <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden