Apple Numbers, cannot make new document

AppleScript
#1

Why does this fail with an error -2710?

tell application "Numbers"
	activate
	-- create a new document and store its reference in a variable
	set theDoc to make new document with properties {document template:template "Blank"}
end tell

returns
error “Numbers got an error: Can’t make class document.” number -2710 from document to class

This is so fundamental… I’ve rebooted. I’ve tried it in SD and Script Editor. It’s like the dictionary from Numbers is hosed.

Note that doing a similar thing in Pages works just fine.

Thanks for any help, and I won’t be insulted if I’m doing something stupid.

#2

Sorry, I cannot be much help. When I run your script here (mac OS Sierra, Numbers 4.3.1), it works as expected.

#3

I’m using macOS 10.13.2 and Numbers version 4.3.1.

I deleted Numbers.app and reinstalled it. Same error.

This is puzzling. I wonder if the Numbers.app is registered in the system incorrectly, or something… “activate” works, but not much else.

Thanks for your help!

#4

Richard,

It doesn’t look like there is an AppleScript error -2710 but there is an OS X error -2710 whose name is errOSACantCreate. This error comes from old “carbon” code and is defined in CarbonCore MacErrors.h. So whatever generated that error is probably very old code being called. You didn’t say what OS you were using. The AS line you gave works for me in Numbers 4.3.1 with no problem and I am running Sierra. It is possible “High Sierra” can’t handle it.

Since this is in fact an attempt to create something I would say this error number is probably coming straight from the OS X error in response to an AppleScript command. Version numbers might be an important factor here. What version of the OS and Numbers are you using?

The later the OS X version gets, the less trustable carbon stuff becomes.

Other than the carbon stuff I don’t have any ideas on what might be causing the problem.

Bill

#5

I solved the problem, but I’m still working out just how it all fits together. I’m reluctant to post this solution as I don’t think this is a generic solution for others to use. Further, it’s almost always a bad idea to flail about in system files that you don’t understand.

  1. Deleted and installed Numbers again. No help

  2. Reinstalled macOS. No help.

  3. Checked all my prefs files with the command line tool plutil. Found a truckload of errors referencing a non-existent .plist file. One error was from Numbers.
    /Users/<home>/Library/Containers/com.apple.iWork.Numbers/Data/Library/Preferences/com.apple.security_common.plist: file does not exist or is not readable or is not a regular file (Error Domain=NSCocoaErrorDomain Code=260 "The file “com.apple.security_common.plist” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/Users/broz/Library/Containers/com.apple.iWork.Numbers/Data/Library/Preferences/com.apple.security_common.plist, NSUnderlyingError=0x7f7f8f108690 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}})

Indeed, that com.apple.security_common.plist file does not exist. A whole bunch of the pref files are symbolically linking to that same non-existent file.
4. Checked with a friend running the same OS, and he does not have that com.apple.security_common.plist file.

  1. Noted that the file
    /Users/broz/Library/Containers/com.apple.iWork.Numbers/Data/Library/Preferences/com.apple.security_common.plist
    had a modified date of sept 2013, and that it is a symbolic link.

6.Quit Numbers

  1. Moved /Users/broz/Library/Containers/com.apple.iWork.Numbers/Data/Library/Preferences/com.apple.security_common.plist
    to~/

  2. Started Numbers

  3. Tried this again

    tell application "Numbers"
    activate
    – create a new document and store its reference in a variable
    set theDoc to make new document with properties {document template:template “Blank”}
    end tell

and it worked.

I’m not sure how this wayward pref file affected AppleScript, but it seems it certainly did. Perhaps the OS was using that old pref file to map the dictionary to the wrong app.

Thanks for your help Bill and Mark.

#6

Well I would have never thought of the apple.security_common.plist file as the problem. But apple.security plists can mess up a lot of things if they missing, corrupted or out of date. They often stop things from running altogether. Glad it worked out for you.

Bill

#7

@thebroz For what it’s worth, the non-generic solution you posted lead me to find a solution to my own similar problem. Thank you!!

I’m trying to automate Pages to open a .doc file and export it as a .txt file, but was getting a doesn’t understand the “export” message error. I’m running macOS High Sierra version 10.13.4 (17E199) and Pages version 7.0 (5576). My understanding of macOS and AppleScript is probably not yet at the level of others on this forum, but I’ll describe my journey in case it’s helpful for anyone else who stumbles onto this search result.

tl;dr: Try open -a Pages in a shell script before running the AppleScript that does the export.

This is a simplified version of my script:

on run argv
    set inputFile to POSIX file (POSIX path of (item 1 of argv as string))
    set outputFile to POSIX file (POSIX path of (item 2 of argv as string))
    
    tell application "Pages"
        open inputFile
        export front document as unformatted text to file outputFile
        quit
    end tell
end run

I realize this may have stylistic issues, but based on trial and error it seemed to be mostly working. I’m running it from a shell script that assembles the arguments; I realize I could probably do everything I need to do with AppleScript, but I’m slightly more comfortable with bash. The inputFile would open properly, but then I would get this error:

./export.scpt: execution error: Pages got an error: document 1 doesn’t understand the “export” message. (-1708)

For some reason my document was not responding to export, but I got the same error when I tried close. To make matters worse, it would sometimes work, perhaps after rebooting my machine or trying it on a clean install of macOS. In my attempt to isolate the issue, I tried make new document, and Googling for subsequent errors lead me to this thread.

I updated my shell script to move the .plist files out of ~/Library/Containers/com.apple.iWork.Pages/Data/Library/Preferences before my AppleScript ran, and then move them back afterward. This worked reliably, but the only problem was that when Pages opened, it thought it was opening for the first time, and presented the two-step “Welcome to Pages” flow with a mandatory License Agreement acceptance. This blocked the script from continuing until I manually clicked through the flow, which undermines the reason to automate this task in the first place.

To work around that, I tried an open -a Pages in my shell script before moving the files out of the Preferences directory. I realize that it is “almost always a bad idea to flail about in system files that you don’t understand”, and it’s even more likely to be a bad idea to do so while the application in question is running, but I was desperate.

Fortunately nothing caught on fire. As I was experimenting with the fix to make sure it was working properly, I noticed that my AppleScript export completed successfully even if I didn’t actually move the .plist files away – launching Pages before running my script seemed to be sufficient to resolve the issue.

A curious, but simple and safe, solution. I would never have thought to try it without first experimenting with the .plist files, so thanks again everyone.

#8

That sounds like a timing issue where your export command was executing before the document had fully loaded and become available to AppleScript.

If you wanted to avoid using ‘open’ (something I’ve seen issues with in a separate context on High Sierra), simply adding ‘activate’ should do the trick.

tell application "Pages"
	activate
	set f to open inputFile
	export f as PDF to file exportFile
end tell
#9

It might — sometimes. The real problem is that some apps open files asynchronously. The only safe solution to that is something like a repeat loop checking for the document’s existence.

#10

FWIW, you don’t need to use Pages for that:

use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
use framework "AppKit"

set theURL to current application's |NSURL|'s fileURLWithPath:posixPath
set {theStyledString, theError} to current application's NSAttributedString's alloc()'s initWithURL:theURL options:(current application's NSDictionary's |dictionary|()) documentAttributes:(missing value) |error|:(reference)
if theStyledString is missing value then error theError's localizedDescription() as text
set theText to theStyledString's |string|()
set theData to theText's dataUsingEncoding:NSUTF8StringEncoding -- or whatever
theData's writeToFile:newPosixPath atomically:true
1 Like
#11

Shane, is your script limited to .doc (MS Word I’m assuming) files, or does it have a broader scope? If so, what is the scope?

#12

It should handle anything that TextEdit will handle. That should be .txt, .html, .rtf, .rtfd, .doc, .docx, .wordml, .odt, or .webarchive. It’s basically what TextEdit uses to read files, and presumably the same as the command line tool textutil.

1 Like
#13

Wouldn’t it be simpler (in that case) to shell-script the conversion with textutil ?
As far as I can tell, Pages’ conversion is slightly better that textutil so there are use cases where using Pages is better that textutil, but if it’s just about getting a dump of the text contents then why not.

#14

If you’re familiar with shell scripting and/or the textutil command, yes. Keep in mind that to a large number of scripters, shell scripting is as foreign as AppleScriptObjC — and its curt nature often makes the code more opaque.

That ASObjC code could also be shortened — and it’s roughly twice as fast.

#15

OK, but I’m curious.

If I use a variable like this

set f to open inputFile

even if the 'activate` is asynchronous, wouldn’t ‘f’ have to have been returned (or throw an error) before the next command executes?

#16

It’s the open I suspect of being asynchronous.

#17

@sphil Thanks – it makes sense that it could be a timing issue. I tried calling activate as well as adding a delay, but wasn’t able to get that to work consistently. I wonder if Pages was taking longer than average to open and read my .doc files.

@ShaneStanley Thanks for pointing that out, that I don’t need Pages! I’ve done some iOS development and somehow it never occurred to me that I could use Foundation in AppleScript, but of course it makes sense that I can.

#18

So would you say that

open inputfile

and

set f to open inputfile

are equivalent then with regards to whether the open command must have returned a result before the next command executes?

In a hodge-podge of different scenarios, I’ve often found that using a variable to capture the result of a command seems to be more robust than just executing the command directly, particulary when that command is a prerequisite for whatever’s coming next.

#19

I don’t really see how, to be honest, unless it somehow introduces a whisker of a delay. The problem is that one of the methods involved in saving moved to a void asynchronous model, and Cocoa scripting, which used to produce the AppleScript result based on the result of this method’s asynchronous predecessor, appears not to have been been updated accordingly. In some cases (that is, when the developer assumes nothing has changed and does nothing) this means no result is returned for the open command, and in others I suspect it’s being returned early.

#20

Worth checking that you do, in fact, have a template called ‘Blank’ on the expected filepath ?

(or that it appears in Script Debugger in the Explorer view of the Numbers dictionary, as a member of the templates collection ?)

(Late post - failed to read the thread - apologies)