[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] AppleEvents for FileMaker?



At 16:01 -0700 6/25/98, Christophe Pettus wrote:
>* The "Commercial Developers' Suite" in Frontier reads the aete resources
>from an application, and produces procedural interfaces based on the
>parameters in the resources.  Very cool for automatically generating glue
>for applications that have not had custom glue written.

Well, sort of.  The generated glue is a good start, but it's not closer to
the truth than the aete is.  And there are many areas in which aetes
inherently lie because the truth cannot be expressed.

For example, many of the Finder events are said, in the aete, to take a
reference to a file or folder...in AppleScript
   file "foo" of  folder "bar" of disk "baz"
(with an assumed <of application "Finder"> on the end).

What Finder can actually take in in those events is that reference, or an
alias, or the strange AppleScript file spec (generated by file
"baz:bar:foo"), or a real FSSpec, or a list of any mixture of those.  [And
if Jon's Commands is present, as it usually is on a developer's machine but
may not be on a user's machine, the plain string "baz:bar:foo" will work,
too, either alone or as a member of that mixed list, because Jon's commands
provides a string to FSSpec converter.]

The aete writer was faced with a language in which could be said either one
of those types (the reference was in fact used) or "anything".  (Or a list
of either references or anything.)  Since the language can't express the
truth, the generated glue doesn't represent the truth.

The suite generally does no worse than the aete it's working with.

And...there are applications whose aete is generated on the fly for one
reason (scriptable plugins) or another (Script Debugger had to be able to
hide its aete to avoid conflicts with the debugee).  So the *right* way to
get the aete for a running app is to send the getAETE event to the app.
For a non-running app, the right way is to look at the bit that says "don't
ready my aete resource, send the event"...if present, launch the app and
send the event; if absent, then grab the aete resource.

I never finished modifying the aete parser in the Commercial suite to do it
right...I did have a version which was hard-coded to send the event and use
the result (which is a chunk of memory just like an aete).  I used it to
make glue for Script Debugger.

   --John
--
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA
Give a man a fish and you feed him for a day.  Teach him to fish,
and you get rid of him for the weekend.

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch