Have an application that is going live in a couple of days. In many of our fillable PDF forms we use:
This worked fine until our company pushed out Adobe Reader X to all of our employees. Now the above function does nothing.
Is anyone experiencing similar? When I say the function does nothing, you click on button that runs the above function, and no new window opens with specified URL.
I am not quite sure what that means. Can you please explain?
This has worked on same client pc before with version 7 - 9. Now doesn't work anymore since upgrade to Adobe Reader X.
Note: ALL other AcroScript functions work properly
Really appreciate any assistance you have.
*** UPDATE *** - I just tested more. The only thing that is NOT working is the second parameter of the launchURL.
If I remove that parameter, or put FALSE, then the URL opens. However, it opens in the same window which is not what we need.
Putting TRUE in there produces no result.
Message was edited by: jred33
Another UPDATE.... You are correct, having the client manually get out of protected mode works. However, how can it possibly be expected for a user to do this?
Is there any other parts of the API where you can trigger a separate window to open with a different URL?
Thanks again for your help....
If Protected Mode is enabled no script will work. You must instruct your users to disable it. It's not that complicated.
I just tried app.launchURL with Reader 10 with protected mode enabled, and it worked just fine. It did pop-up a confirmation dialog, giving the opportunity to block it, so you may want to check the Trust Manager settings: Edit > Preferences > Trust manager
I agree it works, however, I can't get it to open in new window (using the second parameter as true) without disabling the protected mode.
i also agree that it is pretty simple to do... but this application is going on a government website whereI have no control over user community's adobe reader
i need the new window to open as these are help pages that need to popup. If I have in same window when they hit back button fillable PDF loses all data.
You're right, my first test was with the file opened outside of a browser. When I tested the file on a web server, it worked, but not in a new window if protected mode was enabled, just as you've found. I was a bit confused because you initially said it did nothing.
This is probably the intended behavior. I recall thinking when they first added this method years ago that it should be restricted somehow, otherwise a rogue PDF could attempt to open an unlimited number of new browser windows, which can (and did) crash the users machine.
Got the same problem, any insights will be greatly appreciated.
Not exactly professional for me to tell thousands of clients (and potential clients) to check their acrobat settings.
Any workarounds? Can we code this straight from InDesign (my source application)?
By unprofessional, I meant to say that some users can access the links whilst others experience nothing. It would be unprofessional to have a disclaimer for users to check their security settings (not a valid work-around) or something like that.
I determined when this happens.
I have several forms that use "app.launcURL (...)", several years and just the installation of Adobe Reader X users have begun to have different problems.
Some say they are redirected to a page in Adobe, others just the browser opens but is blank, is not going to any page and in other cases non-existent open url like "http://xn--h5a9807h/" or "http://xn--tp-vxc5603s" ... Reader and all with X.
The problem is the length of the URL ... if it exceeds 255 characters failure occurs (which does not happen with earlier versions of Reader).
The following link will leave a form on which you can verify this: http://www.nartexsoft.com/downloads_nartex/adobe/launchUrl-Issue.pdf
For those interested, I've just published a new (free) tool on my web-site that will convert all launchURL() JS-actions to "real" web-links, so it might help solve this problem. Be aware, though, that if you have other code in your link, it will be lost.
We're having a similar problem.
First, an overview of our application. We have a (Java) web application where users can select documents to print. Upon a request, iText generates a PDF (displayed in the web browser with the Adobe Reader plug-in) with 1) an open action to print ("this.print(true);") and 2) a DID_PRINT action to redirect back to the application using launchURL ("app.launchURL();"). This all occurs in the same window; there are no pop-ups.
When we deployed the application, we were using Adobe Reader 9, and everything worked perfectly. Subsequently, we upgraded to X, and now this functionality works sporadically. Sometimes it works fine several times in a row, while other times it doesn't work several times, then suddenly does. Reloading the same PDF may change the behavior from broken to working or vice versa.
To verify this is an Adobe Reader issue and not an iText issue, I've saved off PDFs that initially exhibit the correct behavior. When loading those static PDFs, sometimes they work, and sometimes they don't. That is, the PDF doesn't change, but the behavior in the browser/plug-in does.
Some further notes:
- It seems that launchURL() never works in IE when loading a PDF from the local filesystem. In addition, it seems that if it is working (via a PDF from the server), opening a PDF from the local filesystem in another tab stops it from working in all tabs.
- As far as I can see, launchURL() always works correctly in Firefox, even from the local filesystem. Unfortunately, our users only have IE on their PCs.
I'm hedging a bit above ("It seems") as, because of the sporadic nature of this, it is hard to say for certain what always/never works and what usually/rarely works.
Any ideas? The random nature of this has made it very frustrating to diagnose. Some sort of security setting comes to mind, but one would assume the behavior would be consistent. That is, if a policy was blocking launchURL(), it should always block it, which isn't the case.
Adobe Reader plug-in: 10.0.1.434
Adobe Reader plug-in: 10.0.1.434
"Enable Protected Mode at startup" is greyed out for me. It doesn't appear to be checked, but I'm not sure how to confirm that.
Nevertheless, even if it is enabled, it doesn't make sense that sometimes it would work and sometimes it wouldn't.