process.start problem
-
Hi, I am using Process.Start("file.pdf") to launch the default pdf reader and open a file. This works the majority of the time. However during deployment I came across a few computers where this does not work. It does absolutely nothing. The reader is not launched and the file is not opened. However, on those computers if they manually launch their reader and then run the above code the file gets opened. Has anyone come across this problem before? Does anyone know what is happening? It is not a problem with the reader not being associated with the pdf file format. I know this because when they double click a pdf file from explorer it opens just fine. Thanks, Karl Karl Baum
-
Hi, I am using Process.Start("file.pdf") to launch the default pdf reader and open a file. This works the majority of the time. However during deployment I came across a few computers where this does not work. It does absolutely nothing. The reader is not launched and the file is not opened. However, on those computers if they manually launch their reader and then run the above code the file gets opened. Has anyone come across this problem before? Does anyone know what is happening? It is not a problem with the reader not being associated with the pdf file format. I know this because when they double click a pdf file from explorer it opens just fine. Thanks, Karl Karl Baum
And what exception handling do you have around
Process.Start
? Are you just catching exceptions and not doing anything with the exception data (like displaying a user-friendly error, which is the least you should do)?Process.Start
- the way you're calling it - usesShellExecuteEx
, the same API that the Windows Shell uses when you double-click files. There's really no difference. So then you should ask yourself what the other factors may be. Are you expecting that the current working directory will be the directory in which the EXE is located? This doesn't have to be the case. The working directory can be any directory. So, if this was some sort of help file and you expected it to be in the same directory as your application, then you should construct the fully-qualified path using either theAssembly.Location
property orApplication.StartupPath
like so:string path = Path.GetDirectoryName(Application.StartupPath);
path = Path.Combine(path, "help.pdf");
Process.Start(path);This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
And what exception handling do you have around
Process.Start
? Are you just catching exceptions and not doing anything with the exception data (like displaying a user-friendly error, which is the least you should do)?Process.Start
- the way you're calling it - usesShellExecuteEx
, the same API that the Windows Shell uses when you double-click files. There's really no difference. So then you should ask yourself what the other factors may be. Are you expecting that the current working directory will be the directory in which the EXE is located? This doesn't have to be the case. The working directory can be any directory. So, if this was some sort of help file and you expected it to be in the same directory as your application, then you should construct the fully-qualified path using either theAssembly.Location
property orApplication.StartupPath
like so:string path = Path.GetDirectoryName(Application.StartupPath);
path = Path.Combine(path, "help.pdf");
Process.Start(path);This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
Thanks for your response. I am dealing with exceptions and none are getting thrown. It is also not a problem with the path. I can be sure of this because if you already have your reader open then the code will open the pdf file in your reader. Why would Process.Start behave differently when the reader is already open? This may not be a problem with my code, it may be a problem with the .NET framework, the windows API, or even Adobe's stuff. I am unable to find the cause. Thanks Karl
-
Thanks for your response. I am dealing with exceptions and none are getting thrown. It is also not a problem with the path. I can be sure of this because if you already have your reader open then the code will open the pdf file in your reader. Why would Process.Start behave differently when the reader is already open? This may not be a problem with my code, it may be a problem with the .NET framework, the windows API, or even Adobe's stuff. I am unable to find the cause. Thanks Karl
Some applications - like Office and Adobe Acrobat/Reader - register documents (file monikers) into the ROT (running object table) associated with the application. When a new document is opened, the file persistence handler (typically; this is actually implementation-specific, but is a fundamental technology in COM) checks for running objects and if it is found, activates it. Since the application is running, it doesn't need to be opened again. The new document is opened and registered in the ROT. If this was an existing document, it activates it. It still shouldn't behave differently, however. Perhaps try being more explicit, like so:
ProcessStartInfo psi = new ProcessStartInfo("file.pdf");
psi.UseShellExecute = true;
psi.Verb = "open";
Process.Start(psi);Depending on the operating system this could yield different results. On Win96 the verb "open" is always assumed where with NT its whatever the default is (which could be different than "open"). You can find this out by looking at the File Types tab in the Folder Options control panel. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
Some applications - like Office and Adobe Acrobat/Reader - register documents (file monikers) into the ROT (running object table) associated with the application. When a new document is opened, the file persistence handler (typically; this is actually implementation-specific, but is a fundamental technology in COM) checks for running objects and if it is found, activates it. Since the application is running, it doesn't need to be opened again. The new document is opened and registered in the ROT. If this was an existing document, it activates it. It still shouldn't behave differently, however. Perhaps try being more explicit, like so:
ProcessStartInfo psi = new ProcessStartInfo("file.pdf");
psi.UseShellExecute = true;
psi.Verb = "open";
Process.Start(psi);Depending on the operating system this could yield different results. On Win96 the verb "open" is always assumed where with NT its whatever the default is (which could be different than "open"). You can find this out by looking at the File Types tab in the Folder Options control panel. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]