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

Re: [MacPerl] Applescript and AppleEvents from within MacPerl



Bart Lateur <color@pophost.eunet.be> writes:

>I've noticed that MacPerl allows the programmer to include bits of
>Applescript code. This is a very impressive gimmick, although very useless.

Ouch! That hurt!

>If you try to "compile" an Applescript script from within the script editor,
>it may take well over half a minute to do this, for a 10k source file (about
>3 pages). But this is only once.
>
>In MacPerl, you pass the applescript as *text* to the function call, so it
>gets compiled *every time* (I believe MacPerl uses the Mac's built-in
>functionality for this). Try doing *that*, say, 1000 times in a loop!

True.

>So, here's my question: is it possible to use AppleEvents in a more direct
>manner, than by using MacPerl::Applescript? What about something like
>MacPerl::AppleEvent (I just made this up)?

This has been asked a while ago and I failed to answer. My dilemma is the
following:

I have a pretty good module Mac::AppleEvents. It can both send and receive
AppleEvents, incorporating every style you could possibly wish (toolbox calls,
AEBuild, AEStream). It is currently a shared PowerPC only library, but some
people are still interested in that (and compiling it into a static 68K MacPerl
build would be trivial). However, the interface is totally undocumented, and
it's not even compatible with Inside Macintosh (it took little experimentation
to convince me that a functional style interface, with all output parameters
returned as a *result*, rather than a reference parameter, is a far more
natural Perl interface). Furthermore, error reporting is rudimentary (calls
return either 1 or undef, and the error code in the latter case is only
accessible in Perl 5.002 via the $^E variable, but not in 5.001m).

So what I am going to do is to release the source code tree tonight, but I'm
afraid that this is only going to provoke more frustration from 68K owners and
people who hate reading source code to guess interfaces. What I *really* need
is someone to write sufficiantly good pod documentation to the modules that at
least owners of inside Macintosh will understand the interfaces (anything more
would mean duplication of Inside Macintosh, and that is outside the scope of
the MacPerl project).

>If this is the case (or maybe in the future), how to make a module
>containing the commands for QXP? As a thought, it could be possible to use
>the "glue table" from Frontier for this. This scripting program contains a
>table with 685 entries, most of them 4 character constants, but also some
>2-line scripts like the following:
>
>        on doupdates()
>                return(appleEvent(QXP.id,'XPRS','XUPD'))
>
>Has anybody already done any work in this field? Is there an interest for
>this kind of stuff, or am I the only one?

Rather than using Frontier's glue tables (although I'll be happy to accept code
contributed from Dave Winer and his disciples), I'd like to translate the
standard 'aete' resources into Perl modules. I've corresponded with the
maintainer of MacPython, who apparently has code to do this for Python.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
   "I'm set free to find a new illusion" -- Velvet Underground