Scripting problem with Acrobat 6

I am having a problem with Acrobat 6, i am using ASS and wanted to have my Ass App call this so that acrobat saves a document from a variable and quits the program with out saving agian, it throws an error of Acrobat 6.0 Pro got an error : window doesnt understand the save message, ive tried so many differnt approaches. im stumped :rolleyes:

tell application “Acrobat 6.0 Professional”
set Lacie to “Desktop:File.pdf”
tell PDF Window
–save as linearize
save active doc to Lacie
end tell
quit saving no
end tell

this is what i had before i went to whats above and the thing is this works in script editor but not in ASS im really stumped here and have no idea whats wrong

set effen to (firstName & " " & lastName & " - " & lineCode & “.pdf”) as string
set Lacie to (“PDFs:” & effen) as string
tell application “Acrobat 6.0 Professional”
–activate PDF Window 1
–save as linearize
save active doc to Lacie
–linearize yes
– quit saving no
end tell

any help would be helpful thanks - brad

I cannot solve your problem, just confirm it. But there’s a twist: I have had a script running without problem for a couple of months, with code like this:

save document 1 to fNameWithPath

A few days ago the script ceased to work, and now stops at this very line with the error message “document does not understand the save message”, same as you got.
So the question is, what has happened in between? The customer upgraded from X 10.2.8 to 10.3.2 and Acrobat from 6.0 to 6.0.1. However, returning to 6.0 did not solve the problem, so presumably there is some interaction between Acrobat and certain versions of Panther that creates this problem. I originally created the script under Panther 10.3.1 (I think…) and Acrobat 6.0, but I can’t test it with these specific versions again.
On the other hand, I seem to remember that I tried to get my script to work with Acrobat 5, when I originally wrote it but this failed with the same problem as the current one.

In sum: strange problem, no solution but a few hints in what direction to look.

I had lots of problems saving documents even under Acrobat 5, and ended up using JavaScript to do actual document saving. The saveAs is a member function of the document object. So you can try to locate your document in the open documents array that Acrobat maintains, or just have your document be the only one open and use the “this” identifier. The SaveAs command requires a UNIX-style command path, ie. “/Users/myName/Documents/myPDF.pdf”
When I was developing a script using this before I also had a problem with getting an AppleScript “string” passed correctly into Acrobat, so what I ended up doing was creating the string, writing it out to disk, and then reading it back in and passing the command string to Acrobat using the “do script” command. I have not tested this script with Acrobat 6 yet, but I think it should work.

Well, the problem seems to be solved, for me at least. The solution is simple, but the underpinnings probably a bit complex, and they may have consequences in other circumstances too.
My original script was like this:

tell application “Acrobat 6.0.1 Professional”

set docRef to document 1

save docRef to fNameWithPath – fNameWithPath contains a complete pathname
end tell

This worked for a couple of months, but after update of the OS and Acrobat it stopped working. One attempt I made was to replace the “fNameWithPath” with the actual string it contained, and then the script worked! That is, if I hardcoded the path there was no problem. So why did it not work with a variable? Probably there has been a change in how AppleScript handles coersions between types in one of the OS updates since I created the script. When I used the hardcoded, explicit string it was coerced automatically to a “file specification” (by AS or Acrobat? I don’t know.). The variable fNameWithPath however was typed as string (earlier in the script), and for some reason the automatic coercion didn’t work, so the solution was simply to change the save command to:
save docRef to file fNameWithPath – notice “file”
thus making the coercion explicit.
I will stick to this explanation until proven wrong (and maybe even after that…).