Re: Adobe Reader Process Name
Rivka Licklider
So in my testing, I realized that if Acrobat Reader is already open, I get an i/o exception because the process is already running. So I tried following this post: Detecting a Process is already running in windows using C# .net
So I have two questions.
1) This doesn't work. The Length is always 0 so I'm wondering if I am returning the wrong process or it can't find the process. When I look in Task Manager, that AcroRd32.exe is the name of the process that is being run.
2) Is there a better way to do this? It seems like I'm hardcoding this process into the code and I wasn't sure if there was a better way to catch either other versions of Acrobat (like if there was a 64-bit version), or other PDF viewers in general.
Additionally, I have seen times where a program cannot detect or "work" with a process that is above it in permissions. Make sure that adobe reader is not running under Admin privileges, and if it is make sure your program is too.
If you pass the file path of the PDF file you have just created to Process.Start instead of trying to launch Acrobat Reader, Windows will open the PDF with the default application associated with the .pdf file extension. You will not even need to know what reader they have installed. If no reader is installed, Windows will prompt the user to choose an application to open it with. This is a better option that launching Acrobat Reader directly as it will open the PDF file with the user's preferred reader.
If this is what you are already doing (which I suspect it is from the question), then you are most likely getting the IO exception because the generated PDF file is still open in PDFSharp or your code (i.e. something has it locked), meaning that Acrobat Reader cannot open it. Starting a process that is already running should not cause that error.
Yes, but i believe to have found a work-around solution. By going into the directory, and disabling the welcome screen (due to the fact that the file may be corrupt, and that all other options (such as updating, clean re-install, disabling pdf browser display) have already been tried), I hope this will solve the issue. Will post back the outcome.
Hi, we use Adobe Reader X on our Windows 2003 Terminalservers with Citrix Presentation Server 4.0. Since we upgraded from Version 10.0.0 to 10.1.1 sometimes the process acrord32.exe is still active when user close the program. The problem is that...
Basically the file that is used by the welcome screen (ReaderMessages) has become corrupted (that file is located here on Windows 7 C:\Users%UserProfile%\AppData\LocalLow\Adobe\Acrobat\10.0.) Deleting that file did not help on a long term basis, but by disabling the welcome screen it bypasses that file and will close normally. Unfortunately Adobe does not have a built in way to disable the welcome screen but you can disable it by making a small addition into the registry.
Another way through the closing process of loading system. There is then no need for any changes to the registry, parameters or settings Acrobat Reader. Batch script prepared by default closes Acrord32.exe process and to this end has been designed, but the script can be used to close as any other process too burdensome system, which was suspended when the script calls to the appropriate parameter. If this parameter contains a long name with a space, you must enclose the parameter in quotation marks. Inside the script, to the beginning of the several parameters can be determined, for example. Time of suspension, the time of re-checking, or where the report is to be created (LOG). The script closes all processes meet the criteria for any user, of course, not the system that can not be closed. Can be useful on the server, the work of many users. The script is optimized in order to minimize itself burdened processor.
Hi Rakesh,
I had verified on my end as well, it looks like both Kill process and the other option what mukesh(Task Kill) mentioned was not killing the adobe Reader.
So I tried closing (AcroRd32.exe) under Details in Task manager manually to understand the behavior. I got pop up some thing like this.
"If an open program is associated with this process, It will close and you will lose any unsaved data. If you end a system process, It might result in system instability. Are sure you wan to continue."(Below article related this exception)
To kill the Acrobat 32-bit/64-bit process, you need to identify the correct process name or executable name for the 64-bit version. It's usually "Acrobat.exe" or "AcroRd64.exe" or "AcroRd32.exe". You can verify this by opening Task Manager (Ctrl+Shift+Esc) and checking the "Details" tab for the Adobe Acrobat Reader process. Once you have the correct name, you can use it in Blue Prism to kill the process.
For example, if it's "AcroRd64.exe" or "AcroRd32.exe", you can create an action in the Blue Prism process with the Utility - Environment VBO and use the "Kill Process" action. Set the "ProcessName" input to "AcroRd64" or "AcroRd32" without ".exe".
Works for me.
Continuity between posts is important. In your recent post Qutting Adobe Acrobat Reader, I provided the run shell script solution that killed the application whose real process name is AdobeReader. You can use the UNIX killall command with the marketing product name in the Terminal and simply get this result, because it does not exist in the UNIX process table:
If you refer back to the previous linked post, you will see the syntax that gets the job done, and because AdobeReader is the parent process, it also whacks other affiliated processes: AdobeCRDaemon, RdrCEF, and multiple RdrCEF Helper processes. In my example, I use the SIGTERM (-15) signal with pkill to send a software termination signal to the AdobeReader process, which if it is programmed correctly, will catch that signal and end the application politely by closing open documents, and any children processes, before itself quitting.
Your knowledge bas is in the stratosphere compared to mine. I would " simply" like to quit all running apps, once unfriendly Adobe is killed if it is running (tho it seems that the script runs without error even if Adobe is not running):
No. Each running application that you start, not the operating system, has its marketing name, and the actual process name may be entirely different. That being the case, you would have to know those explicit process names and form an if/else if/else/end if clause for each of those process name conditions. And some of these may intercept a polite signal to quit, and ignore it, thus not quitting the application.
When developing a JavaScript solution, you must have a minimum Acrobat (or Adobe Reader) version in mind. The choice of target application determines, by the table above, the version of JavaScript you should use.
Most JavaScript API are documented for all versions of Acrobat and Adobe Reader, while others are only defined in later versions. Additionally, some APIs are restricted to Acrobat Pro and some cannot be used by Adobe Reader, while others can be used in Adobe Reader only when the document has the appropriate Reader Extension Rights. Again, for a JavaScript solution, all these factors must be considered.
JavaScript is the cross-platform scripting language of the Adobe Acrobat family of products that includes Acrobat Pro Extended Acrobat Pro, Acrobat Standard, and Adobe Reader. Through JavaScript extensions, the viewer application and its plug-ins expose much of their functionality to document authors, form designers, and plug-in developers.
In addition to being available in Acrobat and Adobe Reader, the objects, properties, and methods for the Acrobat extensions for JavaScript can be accessed through Microsoft Visual Basic to automate the processing of PDF documents. See the Interapplication Communication Developer Guide for details.
Some JavaScript objects are static objects that can be used as is and must be spelled as indicated. For example, the app object represents the JavaScript application. There is only one such object and it must be spelled app (case-sensitive).
Many of the JavaScript methods provided by Acrobat accept either a list of arguments, as is customary in JavaScript, or a single object argument with properties that contain the arguments. For example, these two calls are equivalent:
When using Acrobat Pro, if you give an Acrobat method an argument of acrohelp and execute that method in the JavaScript Debugger console (or any internal JavaScript editor), the method returns a list of its own arguments.
For many methods, the file name must have an extension appropriate to the type of data that is to be saved. Some methods may have a no-overwrite restriction. These additional restrictions are noted in the documentation.
Some JavaScript methods, marked by an S in the third column of the quick bar, have security restrictions. These methods can be executed only in a privileged context , which includes console, batch and application initialization events. All other events (for example, page open and mouse-up events) are considered non-privileged.
In Acrobat versions earlier than 7.0, menu events were considered privileged contexts. Beginning with Acrobat 7.0, execution of JavaScript through a menu event is no longer privileged. You can execute security-restricted methods through menu events in one of the following ways:
The #.# version number indicates the product version a property or method became available. If the number is specified, the property or method is available only in versions of the Acrobat software greater than or equal to that number. For Acrobat 8.0, there are some compatibility issues with older versions. Before accessing the property or method, the script should check that the forms version is greater than or equal to that number to ensure backward compatibility.
D: Writing to this property or method dirties (modifies) the PDF document. If the document is subsequently saved, the effects of this method are saved as well. (In Adobe Reader, the document requires specific rights to be saved.)
d3342ee215