Re: Finder's open event has properties? Cal?
Re: Finder's open event has properties? Cal?
- Subject: Re: Finder's open event has properties? Cal?
- From: Chris Nebel <email@hidden>
- Date: Tue, 05 Dec 2000 16:13:56 -0800
- Organization: Apple Computer, Inc.
Peter Fine wrote:
>
Here is the Finder's 'open' command:
>
>
open: Open the specified object(s)
>
open reference -- list of objects to open
>
[using reference] -- the application file to open the object with
>
[with properties record] -- the initial values for the properties,
>
to be included with the open command sent to the application that opens the
>
direct object
>
>
The harder you look at this, the vaguer it becomes. In code that directs the
>
'open' command to an 'application file', it would seem that the application
>
file is the object whose properties are referred to. (To me, using an
>
application as the direct object of the 'open' command is a fundamental
>
anomaly.)
>
>
The Finder's 'application file' object defines the data type of its ID
>
property as 'integer'. Furthermore, it has an explicit 'creator type'
>
property and does *not* have a 'visible' property!
1. The Finder knows how to open things, including applications. That's what its
"open" verb is for. There is no magic translation in AppleScript that turns "tell
application 'Finder' to open application file 'blah'" into "launch application
'blah'". The two commands happen to have the same effect, that's all. The
existence of more than one way to accomplish a task is not a fundamental anomaly.
2. The "with properties" parameter for the Finder's "open" (and for "make new")
does not apply to the direct object, but rather to the verb itself. In other
words, the command "open application file id 'blah' with properties {visible:
false}" is parsed like this:
verb: open
direct object:
class: application file
keyform: id
key data: "blah"
parameter:
key: with properties
data: {visible: false}
Not like this:
verb: open
direct object:
class: application file
keyform: id
key data: "blah"
qualifier: with properties {visible: false}
Therefore, it doesn't matter that application files don't have a "visible"
property, because that's not what it's talking about. The "properties" are extra
parameters to pass along with the "open" command, not qualifiers on which
application file you get.
3. AppleScript is extremely lax about what it will compile. As long as you use
words that it knows, it doesn't much care how you string them together as long as
you follow the basic syntax rules. All sorts of things that don't actually work
will compile, e.g. "RGB color of file id {foo:19, bar:23}". This is something I'd
like to correct eventually, but it's a large and hairy task.
4. You've got a point with the id being an integer vs. a string -- the Finder
dictionary plays a little fast and loose here. Ideally, classes that support the
unique-id keyform should have a matching "id" property, such that saying "item id
(get id of item blah)" gets you item blah back.
Unfortunately, the Finder doesn't do this. It defines an "id" property for items
(which application file inherits), but it's the disk file id, not the creator
type. Saying 'application file id "string"' is syntactically correct enough that
AppleScript will compile it, and the Finder happens to understand it, even though
its dictionary implies that it shouldn't. This is a known bug, but it's unlikely
to be fixed any time soon.
--Chris Nebel
AppleScript Engineering