Re: Finder Scripting
Re: Finder Scripting
- Subject: Re: Finder Scripting
- From: Dave Lyons <email@hidden>
- Date: Mon, 22 Aug 2005 20:29:13 -0700
On Aug 20, 2005, at 5:17 AM, Shane Stanley wrote:
According to the dictionary, one command is "(NOT AVAILABLE) add to
favorites". But now I try it, I see it doesn't actually compile
like that. Then again, "add to favorites" alone won't compile
either. (If I enter "«event fndrffav»" it compiles to "(NOT
AVAILABLE) add to favorites" once, but from then on refuses to
compile.)
I'll try to get this cleaned up for the next big release. If "add to
favorites" has never even compiled right, then that one wasn't doing
it's "compatibility" job anyway, and it can just be removed. Perhaps
others can move into a separate "backwards compatibility" suite.
Moreover, we're not really talking about a script that "works on
both Finder 9 and Finder X" -- the whole point is that these things
_don't_ work under Finder X. Whatever, I'm not sure that there are
many people still writing scripts for both. Brave souls.
I don't know how many people still try, but in some cases, their
presence of this terminology allows a script to *compile* and then do
a run-time check to see what things will work. If the script can't
compile, it can't do the run-time check.
During Tiger development, when I first added what's now called
"computer container", it was called "computer"...and in very short
order I got a bug report that this broke the ability for a script to
check whether it was running on 9 or X by doing something like
computer "sysv" (where "computer" is the old Mac OS 9-compatible
name for "system attribute"). Thus was born the non-conflicting name
"computer container."
In Tiger, [...] you can move but not (always) duplicate. The
problem doesn't happen always, but when it does you see an error
dialog quickly flash up ("Sorry, the operation could not be
completed because an unexpected error occurred, (Error code 0)").
The script editor's log records no error; in fact, the command
returns what would be the result of correct operation. (This makes
trapping it a nightmare.)
And the item has not actually been duplicated? (The return value
refers to a nonexistent item?) -- Have anyone seen this happen with a
"manual" Duplicate, or is it only from a script?
We have no bug reports of this, at least none assigned to Finder
Scripting...if anyone who has seen this could file a bug, that will
be helpful. Any report is better than none, but the more details,
the better, especially in cases like this where it won't reproduce on
demand. Has this been seen when duplicating: (1) a single item, or
multiple items?, (2) documents, folders, packages?, (3) on HFS+ disks
or network disks or something else?, (4) when the items have long
names / short names / strange characters / valid extensions /
unclaimed extensions?, (5) small items or huge items?, (6) 10.4,
10.4.1, 10.4.2?, ... and so on.
Most of those things will turn out to be irrelevant, but one of them
might be crucial, and each specific case reported helps rule out
variables.
The big thing missing is the recording of moving anything. Move a
file, you get "select Finder window 1". Delete a file, you get
"select Finder window 1". Duplicate a file, you get "select Finder
window 1". You can do a whole lot of actions, and all you end up
with is a series of "select Finder window 1/select Finder window 1/
select Finder window 1".
Specifics noted. -- All these operations just don't support recording
yet, and each "select Finder window 1" comes from clicking in the
window, which selects it as a side effect. And it probably shouldn't
bother to record a select for the already-active window.
In truth, I see recordability as a much lower priority than having
other stuff working. Recordability with such big gaps seems like
effort that could have been better expended elsewhere (although
realistically I assume it's a work-in-progress as time permits).
Agreed on the priority, and "as time permits" is exactly what it has
been. The engineering time that has gone into recordability has been
relatively small, and to some degree I tried to do a few of the "hard
for the user to figure out" things first. For example, a user might
easily get the syntax right for moving an item to another folder, but
might be stumped trying to set a List view column's width, which
records like this:
set width of column id creation date column of list view options of
Finder window 1 to 223
On the whole, I agree that the more basic operations need to be
recordable, too.
Cheers,
--Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden