• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: New Office for Mac Beta and Applescript
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Office for Mac Beta and Applescript

  • Subject: Re: New Office for Mac Beta and Applescript
  • From: Christian Prinoth <email@hidden>
  • Date: Fri, 13 Mar 2015 09:29:35 +0100
I just sent feedback to MS about this, let's see what I can get out of it. In the meantime, would you care explaining how I would go about exporting the old terminology and then applying it to new excel?

Many thanks!

On Fri, Mar 13, 2015 at 2:49 AM, has <email@hidden> wrote:
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)

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden



--

Christian Prinoth
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
  • Follow-Ups:
    • Re: New Office for Mac Beta and Applescript
      • From: has <email@hidden>
References: 
 >Re: New Office for Mac Beta and Applescript (From: has <email@hidden>)

  • Prev by Date: Re: New Office for Mac Beta and Applescript
  • Next by Date: Re: New Office for Mac Beta and Applescript
  • Previous by thread: Re: New Office for Mac Beta and Applescript
  • Next by thread: Re: New Office for Mac Beta and Applescript
  • Index(es):
    • Date
    • Thread