Re: Script Editor 'get selection'
Re: Script Editor 'get selection'
- Subject: Re: Script Editor 'get selection'
- From: has <email@hidden>
- Date: Thu, 6 Mar 2003 03:45:01 +0000
John Delacour wrote:
Here are some more constructive comparisons
tell application "Script Editor"
get selection in window 2
--> error "NSCannotCreateScriptCommandError"
end tell
Going by the SE dictionary, and despite the dreadful error message
(even "RTFM, u f00l!!!" would be more help), this appears to be
correct behaviour. You're trying to get a property from an object
that doesn't contain it: according to SE's dictionary, only the
application and document objects have a 'selection' property.
I assume though that you're trying this because other programs, e.g.
Tex-Edit+, have defined 'window' and 'document' as synonyms of each
other. I'm not sure if this is really a good practice or not,
especially now as GUI apps increasingly seem to be moving away from
the "1 window = 1 document" correlation. Witness the inexorable rise
of "tabbed" browser windows, for example. (Although I can remember as
far back as Photoshop 3 allowing multiple views into a document, so
this is hardly a new concept in GUI design.) So I'm cool about that,
as long as there's a way to get the document(s) of a window and
vice-versa. (And maybe some documentation and example scripts that
explain and demonstrate how manipulating windows and manipulating
documents are two distinct activities and how to do it.)
What I'm finding a problem is document objects in text-based apps
that define a single 'text' *property*, instead of the traditional
'character', 'word', 'text', 'paragraph', etc. *elements*. And then
they seem to sort of sneak *undocumented* 'character', 'word', etc.
elements into the document object anyway... only these don't work
quite right, because linefeeds appear in in when using stuff like
'paragraphs of document 1', for example, and 'set character 1 to
"HELLO"' works okay, but 'set characters 1 thru 3 to "HELLO"' messes
up. Meantime, with 'text' being a property instead of an element,
manipulating the document's text elements is kind of a problem.
One other frustration is the tendency of certain dictionaries to
list, say, 'application', 'document', and 'window' classes under the
Standard Suite, only to list them again, by the very same names,
under the individual application suite where they acquire additional
properties and elements unique to the app. (Reading SE's dictionary
just now was driving me batty, which is why I bring it up.)
Understanding well-written dictionaries is hard enough work in itself
without having two separate entries for something that claims to be a
single class. This smells awfully like internal implementation
details leaking out where they shouldn't, but if there's some genuine
reason for not combining the two into a single dictionary item then
they should at least be distinguished by name so we know which is
which: 'abstract application' and 'application'; 'abstract document'
and 'document'; etc.
HTH
has
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.