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: email@hidden
- Date: Tue, 5 Dec 2000 17:36:44 -0500
On Mon, 04 Dec 2000 19:26:05 -0500,
Peter Fine <email@hidden> stated,
>
But the ID property of the Finder's 'application file' object is supposed to
>
be an integer, not a string. See below.
It sure is inconsistent. What the Finder gives you as an ID is not what the
Finder takes as an ID. The ID property of an application file is, as you point
out, an integer, because application file inherits this from "item". This ID is
the HFS file number.
But, in the context of getting an application file by unique ID, the Finder
behaves differently: it uses the creator code to access the proper application
in the Desktop Database.
It isn't symmetric, and that's why its confusing. "file ID nn" isn't the same
as a filter expression "file whose ID is nn". In the best of all worlds, the
Finder would provide the file, folder, or disk with the HFS number nn when given
the command "item ID nn" (where nn is a number), and also give the proper
application file when asked for 'application file ID "XXXX"'. (This will
probably be implemented right after the "entire contents" and "filter" bugs are
fixed. ;-) )
I suspect that when the Scriptable Finder was being developed, the folks at
Apple first said, "we can implement ID properties for things, by giving back the
HFS integer. Its a unique identifier, just like ID is supposed to be." Then
later in development, the problem of identifying applications by their creator
codes came up, so they pressed the Unique ID key form into service, without
considering that the ID the Finder gives is not the ID the Finder takes.
>
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.)
AppleScript and the Finder do some detail-hiding for you when you use the "open"
command. You can open a file, in which case the Finder locates the proper
application to open it. If the file you are opening is itself an application,
the Finder instead runs it.
>
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.
Don't let the proximity of these two clause make you think that one effects the
other. The parsing is
open
- file to open: (application file ID "xxxx")
- property record pass on: {visible:false}
What AppleScript and the Finder do in executing this statement goes like this:
First, the Finder resolves the 'application file ID "xxxx"' argument. It hits
the Desktop Database and finds, say, 'file "FFF" of folder "FOLD" of disk "Disco
Volante". It then starts the process of opening that file. It notes that the
file is an application, and thus will open it by running it. It constructs a
"run" Apple Event, and tacks on a <<class prdt>>: {visible:false} argument, and
sends the run event off to the application.
Try this at home! Save the following script as an application.
-- file "Open Example" of desktop
on run given <<class prdt>>:props
display dialog "Run " & class of props
end run
on open fileList given <<class prdt>>:props
display dialog "Open " & class of props
end open
Then tell the Finder to open it, in two different ways,
tell application "Finder"
open file "Open Example" of desktop with properties {visible:false}
open file "Something Else" using file "Open Example" of desktop with
properties {visible:false} -- <-- watch for wrapping!
end tell
The first "open" line will invoke the "Open Example" script's run handler, and
will pass in the stated properties as an argument. (Specifically, as the
<<class prdt>> parameter.) The second "open" will invoke the script's open
handler, with the file in a list as the direct parameter, and the properties
again as the <<class prdt>> parameter.
>
Seems to me that Paul's code should not have compiled or should have errored
>
at runtime.
There are really two things going on in Paul's code. First, getting to an
application in the Desktop Database with the reference form,
application file ID "xxxx"
That's an important idiom for AppleScripters to know. The creator code ID here
is different than the HFS number ID the Finder gives back if you ask for a
property.
The second issue is the "open ... with properties" command. Whether this does
anything at all depends on the final application, not the Finder. If the
application knows to look for a <<class prdt>> argument, and takes action based
on what it finds, then you've got something. But offhand, I don't know of any
application that responds to this argument. Perhaps the original example (which
I can't dig up now) used a specific application that took the "{visible:false}"
property record and set its visibleness appropriately. But that's an
application function, not a Finder function.
And a further difficulty is that if you open an application with properties, the
Finder sends a "run" ('oapp') Apple Event, not an "open" ('odoc') Apple Event.
The receiving application 'run handler' needs to look for a properties record
the same way as the 'open handler'. (These 'handlers' are in quotes because the
application may not implement them in separate modules. But still, it needs to
act on properties parameters provided in both the 'oapp' and 'odoc' events.)
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden