Re: Better Open Dictionary
Re: Better Open Dictionary
- Subject: Re: Better Open Dictionary
- From: has <email@hidden>
- Date: Thu, 6 Mar 2003 02:41:37 +0000
John Delacour wrote:
I had a notion Script Editor 2 might be a cocoa application and as
we've been told cocoa doesn't do selection -- that's why TextEdit and
Mail can't do it.
I thought it was that the Cocoa frameworks didn't implement it as a
standard "free" feature. Presumably there's nothing to stop
individual application developers implementing their own version in
their own way. (Or did I pick this up wrong?)
However this is the first application I've ever seen that can do
selection but not do 'selection as string', [...]
tell application "Script Editor"
selection as string
end tell
Hmmm. The dictionary lists 'selection' as an object (which I don't
have a problem with) and 'Class selection' indicates a 'contents'
property, so I can see why this mightn't work and why it might be
correct that it doesn't work. What you actually want is:
tell application "Script Editor"
contents of selection
end tell
What is odd is that 'get selection' returns something that looks like
a typical reference to the document's text, but actually isn't:
tell application "Script Editor"
selection
end tell
--> characters 42 thru 45 of document 1
Seems to me this could be very misleading for a scripter who doesn't
grok the finer points of objects, object models and application
dictionaries. Also, it refuses a polite 'get class of result' with
another incomprehensible error message, so there's no way of
determining programmatically what the thing is either. I'm not sure
what best practice on evaluating 'selection' is, but the inability to
get its class certainly looks like a bug to me.
One other note: the application object's 'selection' property only
seems to work when gotten from SE itself. Trying to get the
property's value (or that value's contents) from Smile fails to
return a result, which is probably another bug. (Getting a document's
selection property seems to work okay, however.)
--> "NSReceiverEvaluationScriptError: 5"
--> Extremely helpful error message !!
Indeed. I have the feeling that AppleScript and scriptable apps have
always had a tradition of cryptic and unhelpful error message, but
these are particularly hopeless. So here's a thought for application
developers: AppleScripters make _lots and lots_ of mistakes;
hundreds, thousands, millions of big, fat mistakes. What's more, this
is often normal practice: if a scripter isn't sure how something
works (e.g. they're a learner or the application is
under-documented), they'll keep guessing until they hit upon with
something that does. Other times, accidents just happen.
Comprehensive error messages in response to the user's mistakes
should be seen as an _essential product feature_, every bit as
important as implementing scriptability in the first place;
potentially marketable too.
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.