MS Word: What known gotchas are there when opening documents?
MS Word: What known gotchas are there when opening documents?
- Subject: MS Word: What known gotchas are there when opening documents?
- From: has <email@hidden>
- Date: Sat, 19 Mar 2016 18:55:47 +0000
Hey folks,
Have I mentioned before just how much the AppleScript world likes to
bust my nuts? Especially when tight deadlines are involved? Gahh.
So on Friday I handed off a lovely little v1 workflow to a user that
sucks a load of pack copy out of a bunch of tables in a .doc file and
drops it into a collection of Back of Pack panels (nutrition,
ingredients, etc.) in Illustrator, ready to be dropped straight onto
artworks. Everything been tested repeatedly and is running perfectly, a
lovely productive tool for them and a cracking sales pitch for me. It
has been a good week. But the moment the little wretch is out of my
sight, it craps out right at the start of its very first run:
OSERROR: -1712
MESSAGE: Apple event timed out.
COMMAND: app('/Applications/Microsoft
Word.app').open(mactypes.Alias('/Users/admin/bop-workflow/data/ABC123-1_pack.doc'))
Now, I've never done much Word scripting beyond the typical "what's the
minimum code needed to get all the data I require the hell out of it and
into something sane". (And curse you, textutil, for not doing a usable
.doc-to-.docx conversion, which'd have let me use python-docx and
bypassed Word entirely.) So unlike Illustrator scripting, I am
completely unfamiliar with the no doubt myriad obscure and delightful
ways in which Word might screw one's day. Since the Apple event timeout
occurs on Word's `open` command, I'm guessing something inside Word is
blocking the `open` event, preventing the file from opening - most
likely a dialog box of some sort (something that gives me regular
nightmares in AI; font management plugin authors deserve a special
hell); perhaps that annoying nearly-full-screen window which appears at
every launch offering ten zillion ways to get started?
Of course, this wretched code, having only gone and humiliated itself in
front of the user's boss and his boss too, is apparently working
perfectly again today, which just makes blind, remote debugging over
email even more harder. I should be able to retrieve that machine later
next week to attempt to replicate the problem myself, but I won't have a
lot of time to figure out and implement a robust solution (it's supposed
to be deployed the week after, and I won't be doing that deployment
either). Plus it's supposed to be going down south for another
presentation (again without me) on Monday, so the last thing anyone
needs is it going pear-shaped there as well.
So, to folks here who've already hard experience in making Word scripts
bombproof for other users (regardless of how an individual user's
Word.app might be set up and used, as I can't change anything about
that), what are the gotchas you already know of, and how do you reliably
deal with them? And is there any way you can manage to list them all
within the next 24 hours? ;)
Many thanks,
has
p.s. The machine in question is running 10.10 and Word 2016, btw,
neither of which I currently have access to myself. I'm still using a
well worn copy of Word 2011 OMM, and I've altered its preferences a fair
bit over the years, so if folks are aware of differences between
versions that might cause issues to arise on one but not the other, or
if Word's just sufficiently inconsistent and cranky that the only way to
ensure a script will always work is to set up a clean test box or three
to run the same script against multiple configurations, let us know.
_______________________________________________
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