Action Wizard custom action fails
Copy link to clipboard
Copied
I have an Action Wizard custom action (used previously in Acrobat Pro XI), which uses some JavaScript to add previous/next page, print and home buttons on every page of a document. This worked well before upgrading to DC, but now fails to complete if the document size goes beyond a handful of pages. I really do need a quick solution to this issue, any idea why this is not working in DC? I have tried to run this same custom action on Mac and PC versions of Acrobat Pro DC with the same result.
Copy link to clipboard
Copied
That's very strange... What exactly goes wrong, though? Is there an error message of some kind? If so, what does it say?
Copy link to clipboard
Copied
No messages of any kind, just sits forever (Not Responding). Task manager/Activity monitor Acrobat.exe reports 24% CPU usage... so I guess it may may respond after waiting several hours (I have waited an hour or two), but the same Action takes a minute or two in Acrobat Pro XI.
Copy link to clipboard
Copied
What's your exact version of Acrobat, and OS version?
Copy link to clipboard
Copied
2015.006.30033 Windows 7 Professional
Copy link to clipboard
Copied
Can you post your code, and/or the actual Action file?
Also, are you processing files that are saved locally, or on a network drive?
Copy link to clipboard
Copied
The code is below, it runs locally, but takes button images from the network... not changed from Acrobat Pro XI where it works fine on a slower machine with the same OS on the same document.
/* Put script title here */
var inch = 72;
for (var p = 0; p < this.numPages; p++) {
// Position a rectangle (.3 inch, .3 inch)
var dRect = this.getPageBox( {nPage: p} );
var uRect = this.getPageBox( {nPage: p} );
var pRect = this.getPageBox( {nPage: p} );
var hRect = this.getPageBox( {nPage: p} );
var fRect = this.getPageBox( {nPage: p} );
dRect[0] = 817
dRect[2] = 842
dRect[1] = 72
dRect[3] = 97
if (p != this.numPages - 1) {
var Nxt = this.addField("Next", "button", p, dRect )
Nxt.setAction("MouseUp", "this.pageNum++");
Nxt.delay = true;
Nxt.highlight = "none";
Nxt.display = display.noPrint;
Nxt.buttonPosition = position.iconOnly;
Nxt.buttonScaleHow = scaleHow.proportional;
Nxt.buttonScaleWhen = scaleWhen.always;
Nxt.buttonFitBounds = true;
Nxt.buttonImportIcon("/X/navICONS/next.pdf");
//Nxt.buttonImportIcon("next.pdf");
Nxt.delay = false;
}
else {
var Stp = this.addField("End", "button", p, dRect )
Stp.delay = true;
Stp.highlight = "none";
Stp.readonly = true;
Stp.display = display.noPrint;
Stp.buttonPosition = position.iconOnly;
Stp.buttonScaleHow = scaleHow.proportional;
Stp.buttonScaleWhen = scaleWhen.always;
Stp.buttonFitBounds = true;
Stp.buttonImportIcon("/X/navICONS/stop.pdf");
//Stp.buttonImportIcon("stop.pdf");
Stp.delay = false;
}
uRect[0] = dRect[0]
uRect[2] = dRect[2]
uRect[1] = dRect[1] + 28
uRect[3] = dRect[3] + 28
if (p != 0) {
var Prev = this.addField("Previous", "button", p, uRect )
Prev.setAction("MouseUp", "this.pageNum--");
Prev.delay = true;
Prev.highlight = "none";
Prev.display = display.noPrint;
Prev.buttonPosition = position.iconOnly;
Prev.buttonScaleHow = scaleHow.proportional;
Prev.buttonScaleWhen = scaleWhen.always;
Prev.buttonFitBounds = true;
Prev.buttonImportIcon("/X/navICONS/prev.pdf");
//Prev.buttonImportIcon("prev.pdf");
Prev.delay = false;
}
else {
var Stp = this.addField("End", "button", p, uRect )
Stp.delay = true;
Stp.highlight = "none";
Stp.readonly = true;
Stp.display = display.noPrint;
Stp.buttonPosition = position.iconOnly;
Stp.buttonScaleHow = scaleHow.proportional;
Stp.buttonScaleWhen = scaleWhen.always;
Stp.buttonFitBounds = true;
Stp.buttonImportIcon("/X/navICONS/stop.pdf");
//Stp.buttonImportIcon("stop.pdf");
Stp.delay = false;
}
pRect[0] = dRect[0]
pRect[2] = dRect[2]
pRect[1] = uRect[1] + 28
pRect[3] = uRect[3] + 28
var Prnt = this.addField("Print", "button", p, pRect )
Prnt.setAction("MouseUp", "app.execMenuItem('Print');");
Prnt.delay = true;
Prnt.highlight = "none";
Prnt.display = display.noPrint;
Prnt.buttonPosition = position.iconOnly;
Prnt.buttonScaleHow = scaleHow.proportional;
Prnt.buttonScaleWhen = scaleWhen.always;
Prnt.buttonFitBounds = true;
Prnt.buttonImportIcon("/X/navICONS/print.pdf");
//Prnt.buttonImportIcon("print.pdf");
Prnt.delay = false;
fRect[0] = dRect[0]
fRect[2] = dRect[2]
fRect[1] = pRect[1] + 28
fRect[3] = pRect[3] + 28
var Fnd = this.addField("Find", "button", p, fRect )
Fnd.setAction("MouseUp", "app.execMenuItem('Find');");
Fnd.delay = true;
Fnd.highlight = "none";
Fnd.display = display.noPrint;
Fnd.buttonPosition = position.iconOnly;
Fnd.buttonScaleHow = scaleHow.proportional;
Fnd.buttonScaleWhen = scaleWhen.always;
Fnd.buttonFitBounds = true;
Fnd.buttonImportIcon("/X/navICONS/find.pdf");
//Fnd.buttonImportIcon("find.pdf");
Fnd.delay = false;
hRect[0] = dRect[0]
hRect[2] = dRect[2]
hRect[1] = fRect[1] + 28
hRect[3] = fRect[3] + 28
var Hom = this.addField("Home", "button", p, hRect )
Hom.setAction("MouseUp", "this.closeDoc(true);");
Hom.delay = true;
Hom.highlight = "none";
Hom.display = display.noPrint;
Hom.buttonPosition = position.iconOnly;
Hom.buttonScaleHow = scaleHow.proportional;
Hom.buttonScaleWhen = scaleWhen.always;
Hom.buttonFitBounds = true;
Hom.buttonImportIcon("/X/navICONS/home.pdf");
//Hom.buttonImportIcon("home.pdf");
Hom.delay = false;
}
Copy link to clipboard
Copied
I recommend you try to move the images locally, and see if that makes a
difference.
On Wed, Mar 29, 2017 at 6:07 PM, andye88570511 <forums_noreply@adobe.com>
Copy link to clipboard
Copied
I've tried not having images at all... same problem.
I restate, the issue is not there in Acrobat Pro XI. The code and the images also work fine in Acrobat Pro DC with just a handful of pages, so there cannot be something amiss with the code. The problem seems to be the way DC handles Action Wizard actions, as it performs very badly with larger documents. What are you not understanding? Are you from Adobe support? Can we escalate this issue?
Copy link to clipboard
Copied
I'm not from Adobe support, just a fellow user. But it seems like my efforts trying to help you out are not appreciated, so I'll stop replying. Maybe someone else will like to help you out...
Copy link to clipboard
Copied
My apologies, your input is appreciated, but not that helpful. You seem to be user with less knowledge than me. I need expert support from Adobe. Thanks for stopping your replies, I don't want this issue to become a user conversation.
Copy link to clipboard
Copied
You can contact the Adobe support.
Copy link to clipboard
Copied
While I understand that you didn't experience the problem in Acrobat XI, I suspect that the problem is, in fact, your code; it's horribly inefficient. You just didn't see the problems in the earlier version because of the way the screen was drawn... or more correctly, not drawn and possibly because of the way files are now opened in DC. There may have also been an update to the JavaScript engine causing minor changes to the way the code gets executed that introduce delays that get exacerbated with each loop of your action.
Here are a few suggestions that I'm sure will restore your action to perform the way it used to.
- Define the buttons outside the "for" loop. They're all identical. Currently, you're making Acrobat open a PDF every time you create a button causing a HUGE amount of unnecessary overhead. You're also bloating your PDF by creating a new button object on each page. Defining the buttons once will allow Acrobat to store the button once and reference it as many times as needed.
- Calculate the page positions outside the "for" loop unless your page sizes might be different per page, if so, calculate the rects inside the loop but streamline the code. Currently, you're calling getPageBox 5 times to get the exact same rect.
- Remove the lines that set the field delay property. Instead set the delay property of the document to true before the "for" loop and then to false after the loop. Currently you are asking Acrobat to regenerate the appearance each time the button a created, another computationally expensive task.
Copy link to clipboard
Copied
The problem is with Action Wizard implementation in DC, not the code. If the code is assigned to a button it works. Any other ideas?
Copy link to clipboard
Copied
I'm still going to guess that the problem has to do with changes to the way the DC is rendering the PDF and attempting to render the changes you're making to the current file during an action. When assigned to a button, the file is opened and rendered before you get a chance to hit the button and run the code.
Copy link to clipboard
Copied
I've written automation code lately for adding buttons to >1k page docs. Acrobat seems to get slower and crash more with every upgrade to DC. When adding buttons (or any annotation) to every page in a large doc, there are some rules to follow that are helpful.
1. minimize the number of things that are done in the loop. Ideally just create the buttons. Don't perform any other tasks. In your case, since the buttons all have the same name, you can set them up one time at the end and the params will apply to all.
2. delete all variables that contain large(ish) data.
3. Wait. Acrobat may just be slow. Sometimes it can take an hour to complete a large document. Of course sometimes Acrobat just crashes.
This doesn't necessarily address the "Action" only issue, but my belief is that the real issue is with JS memory management. Hence the rules. It's possible that JavaScript in an Action is managed even more poorly than normal
Use the Acrobat JavaScript Reference early and often
Copy link to clipboard
Copied
I guess we just have to accept that, with each new iteration of Acrobat Pro, JavaScript execution gets slower and more unreliable. This is a sad truth. On a positive note, my code writing is improving. Thanks for the replies
Copy link to clipboard
Copied
I have a conspiracy theory about that. I happen to know for a fact that there are people at the highest levels of Acrobat development that are anti-JavaScript. They hate it because they are PDF originalist. They think PDF should be a static presentation format. That interactivity, and especially scripting, muddies the purity of PDF. Scripting allows almost anyone to automate processes and turn PDFs into mini applications, making it wildly popular with the unclean masses. This anti-JS cabal can't get rid of it outright because it's popularity and market value. So, they are scheming to slowly make JS useless through deliberate inefficiencies, corrupting it from the inside out.
ahhh hahahaha,
Or maybe not
Use the Acrobat JavaScript Reference early and often

