Christian Prinoth wrote:
> Also, my attempts to script it via appscript have been
(partially) unsuccesful so far, see below. I know appscript is
unsupported and obsolete, but it is still very useful.
Appscript isn't obsolete: that'd mean it's been replaced by newer
and better AE bridges, but the only newer options (SB and JXA) are
worse [1]. It is, however, effectively a "legacy API" because the
Carbon APIs on which it relies were made "legacy status" in 10.6,
and no Cocoa equivalents to those APIs have been provided either
before or since.
I have [belatedly] filed a couple Radar feature requests on those
missing Cocoa APIs, plus a third ticket on a longstanding bug that
Apple have still to fix, complete with copy-n-paste solutions to
make it as easy as possible for them:
http://openradar.appspot.com/19169736
http://openradar.appspot.com/19169791
http://openradar.appspot.com/18944184
Personally I'm not going to hold my breath for Apple to address any
of these issues [2], but you and anyone else are welcome to file
duplicates if you wish as that, in theory, tells Apple that at least
someone in the world still cares.
> {aem.AEType('pcli'): [], aem.AEType('XiEc'): True,...}
Yeah, that's a recurring problem with Carbon apps that have
AETE-based dictionaries. Unlike AppleScript, which uses the
deprecated OSAGetAppTerminology() function (or something like it) to
retrieve local apps' terminology and only uses 'ascrgdte'
("GetDynamicTerminology") events when retrieving remote apps'
terminology, appscript relies on 'ascrgdte' events for both local
and remote apps. Unfortunately, every so often one of these old
Carbon workhorses manages to break its standard 'ascrgdte' handler
such that it no longer returns the correct terminology. e.g. iTunes
had a brief wobbly circa
10.6.3, Finder's been broken this way since 10.8 or 10.9, and a
couple third-party Carbon apps have over the years developed the
problem too.
I _think_ what happens is that the developers casually flip the
"NSAppleScriptEnabled" flag in their Info.plist to true, since,
yeah, their app supports AppleScript, right? Unfortunately, the name
"NSAppleScriptEnabled", like most jargon in the AS world, is a giant
honking misnomer: it should actually be called
"NSCocoaScriptingEnabled", because what it does is activate the
CocoaScripting framework's default Apple event handling features.
Which includes CS automatically installing its own 'ascrgdte'
handler on top of the original Carbon implementation's own. In an
app that still relies on classic AETEs (not least because SDEFs
introduce various problems of their own), this is a Bad Thing,
because now CS's 'ascrgdte' handler returns CS's default SDEF-based
dictionary in place of the app's own.
In AppleScript, this means that Remote Apple Event users can no
longer get terminology from the remote app so both of them have to
muck about with 'using terms from <local app>' blocks instead.
But since appscript relies on 'ascrgdte' events for local
terminology too, it always ends up with a dictionary that's missing
a whole bunch of terminology, in which case all it can do is fall
back to using raw AE codes via its lower-level aem APIs (appscript's
equivalent of using raw chevron syntax in AS). It is _very_ hard to
kill appscript completely (it was hardened through experience to
cope with even the craziest, crappiest, and demented scriptable
apps); that said, a few hours of scripting a monster app like Excel
using nothing but four-char codes and you'll probably want to kill
yourself instead.
Appscript does provide other fallback options as well, e.g.
exporting the correct terminology from an older version as a 'static
glue' module, then importing that when scripting the new version.
But honestly, it's recurring crap like this - in addition to Apple's
ongoing War on Carbon and its attitude to pro users in general (Hi,
Xserve/FCP/Aperture users!) - that finally convinced me that this is
not a battle that appscript or its users can win, which is why I
finally pulled support on the project. I do still use appscript
myself - heck, I even have major new product [3] built on top of it
- but these days I'm only concerned with automating Adobe apps, so
have the "luxury" of being able to ditch Apple events entirely and
switch to Adobe's C++ APIs any time I feel life is getting too
pleasant or easy. But I'm not going to tell anyone else that they
can trust appscript as a reliable platform for building their
long-term futures on when I know Apple can pull the rest of the rug
from under it any time it likes (Hi, Xserve/FCP/Aperture users!).
If appscript is still important to you, all I can suggest is that
you file a bug report with MS, letting them know that Excel '15 (and
possibly other apps too) have broken their 'ascrgdte' event
handlers, and pointing out that this is a bit of a hassle for
AppleScript users wishing to control those apps via Remote Apple
Events. (You're welcome to include the above theorising too if it'll
help them find the bug - it may or may not be correct for some/all
cases, but it's a starting point at least.)
HTH
has
--
[1] Not just slightly worse but still fixable, mind, but "borked by
design and wouldn't touch them with a bargepole for any serious or
professional use" worse.
[2] Since fixing all three issues would be 1. extremely low priority
for Apple (as in halfway-to-China low), which at best doesn't give a
flying crap about AppleScript and at worst wishes it'd FOADIAF; 2.
assigned to the currently AppleScript engineers who are even less
likely to want to fix them as to do so would be an effective
admission that their own works suck monkey nuts; and 3. liable to
delight me to such a degree that I might even say something nice
about the AS team for a pleasant change - and the universe hates the
idea of me being happy WAY too much ever to permit that.
[3] Manta Toolkit (http://www.mantasystems.co.uk/docs.html)
|