Re: [MacPerl] MacPerl aete reader

[John W Baxter <jwblist@olympus.net>]

At 18:21 -0500 3/28/97, David C. Schooley wrote:
>There are a couple of bugs...
>1) I'm not convinced that the flags (LIST, ENUM, etc...) are always, if
>ever, correct.

The aete design prevents correctness in many cases.  Just one example:

Finder, in most of the places it says it accepts an object representing a
file (directory, etc) really accepts an object
    file "foo" of disk "bar"
an alias
    alias "bar:foo"
a file spec (a magic conversion from the storage format used for)
    file "bar:foo"

or a list of any mixture of the above.
[If Jon's Commands is installed, Finder also appears to accept file path
strings
    "bar:foo"
because Jon's Commands installs a TEXT to 'fss ' coercion.  Without Jon's
commands, that form is an error.]

Finder Scripting Extension's aete writer had two choices:
   1.  something like what s/he/they did
   2.  list of anything
(I think s/he/they made the right choice.)


>2) Some applications store parts of the aete in strange places. FrameMaker
>is an
>example of one that does this. As a result, not all of the aete gets
>converted.

If an application's 'scsz' resource has the flag set which says "always
send me a GetAETE resource", you should launch the app and send that event.
The reply is laid out like an aete resource...the app most likely builds
the aete live while responding to that event (QuarkXPress inserts the aete
information from active plugins, for example).

If the app is running, it's not wrong to send the event even if the app
doesn't deal with it:  AppleScript installs a system handler which catches
unhandled getAETE events and digs the aete resource out of the app (that's
why the app must be running for Script Editor to get its Dictionary if it
is on a remote machine).

I'll be taking a look at your aete reader when I get time (which means "Not
real soon", sorry to say).

   --John

--
John Baxter (Born before ENIAC, but not by much.)
   jwblist@olympus.net      Port Ludlow, WA, USA