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: Peter Fine <email@hidden>
- Date: Mon, 04 Dec 2000 19:26:05 -0500
on 12/4/00 5:42 PM, email@hidden at email@hidden wrote:
>
The construct 'application file id "xxxx" ' is a standard reference form,
>
specifying an object of the Finder by its ID. It returns a Finder 'file'
>
reference. ('file "SurfWriter" of folder "SurfOffice" of disk "Big Disk" ')
>
The ID reference form is pretty wide-open to the particular application to
>
interpret. If you read the section in Chapter 5 (Objects and References) of
>
the AppleScript Language Guide, you'll see it says,
>
>
Applications are not required to support ID properties. To find out
>
if or how an application uses ID properties, see the documentation
>
for the application.
>
>
Now it turns out that the Finder dictionary says you can get application files
>
of the Finder by their ID property, (which works as we see). It also says you
>
can get application files of a container by their ID, and that doesn't work.
>
>
Its not a coercion, is simply the standard Apple Event form UniqueID 'ID '
>
key. Not as common as reference by name or by index, but still valid. The
>
Finder has to do the work of actually interpreting that reference form.
But the ID property of the Finder's 'application file' object is supposed to
be an integer, not a string. See below.
>
>
"Peter Fine" <email@hidden> was quoted by Paul to have said on 12/4/00 9:47
>
AM,
>
>
>> Apparently, AppleScript knows to translate "open file
>
>> id "foo" with properties {visible:false}" into "launch app "foo"" if the
>
>> file is an app. Since your code compiles without complaint and performs its
>
>> trick at runtime, the analogy to a coercion seems apt. Whether it falls
>
>> within the strict definition of a coercion, however, I don't know. I thought
>
>> that when you coerced something you were transforming one data type into
>
>> another. That's not exactly what's happening here.
>
>
Again, look at the Finder's dictionary. The 'open' event includes a "with
>
properties record" argument. Its explicit.
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!
So 'open application file ID "xxxx" with properties {visible:false}' Has two
glaring errors. First, the ID reference form for this object should be an
integer, not a string. Second, this object does not have a 'visible'
property.
>
>
But I tried 'open application file ID "R*ch" with properties { visible:false }
>
'
>
and got an ordinary startup by BBEdit, while "launch app..." gives nothing.
>
They aren't the same.
I know 'open' and 'launch' are not the same. For one thing, 'open' is an
application command but 'launch' is global AppleScript.
>
"open application... with properties" sends an "open"
>
event to the app, with a <<class prpt>> argument. That's going to invoke a
>
handler in the application, which will have to interpret the property list
>
provided and do the right thing.
>
>
Launch, on the other hand, causes the system to load the application program
>
into memory and start it running, but doesn't send it a "run" Apple Event.
>
And that's not the same thing as being background-only, or not visible, or
>
hidden in the Finder.
Seems to me that Paul's code should not have compiled or should have errored
at runtime.
Peter