Problems opening pdf with openURL, openDocument

[IPguy]

One of my users is unable to open the .pdf help file my program points to.  Using the exact program, I'm not having any issues on any of my test systems.

I've tested this on Vista-32 and win7-64.  My user is having issues on win7-64.  He does have a full version of Adobe CSS suite installed.  Any clue if that might cause an issue?

My user does not see any error messages and does not see the .pdf file open.

Here is my code:

The file exists and he can double click on the file to open it without problem.

Thoughts / suggestions?

Code: [Select]

Procedure TfRIMMain.mHelpHelpClick(Sender: TObject);
// Opens the pdf document file
var
  DocFullFN : string;
Begin
  DocFullFN := RimAppDir + PathDelim + DocFileName;

 Case FileExists(DocFullFN) of
    True :  openURL(DocFullFN);
    False: ShowMessage('Document: ' +  DocFullFN + ' not found');
  end;

End;               
   

[IPguy]

This gets more interesting.

As mentioned above, openURL will not open the pdf file.
I just confirmed the same issue with openDocument.
However, tProcess does work.

Any thoughts?

app built with: 0.9.31-36282, 2.6.1, win32-vista
works on my win32-vista and my win7-64, but not on my customers win7-64 system. 

Code: [Select]

 
  AProcess := TProcess.Create(nil);
  sLocalFN := 'explorer.exe ' + DocFullFN;
  AProcess.CommandLine := sLocalFN;
  AProcess.Options := AProcess.Options + [poWaitOnExit];
  AProcess.Execute;
  AProcess.Free;   

Code: [Select]

    Case FileExists(DocFullFN) of
      True :  openDocument(DocFullFN);
      False: ShowMessage('Document: ' +  DocFullFN + ' not found');
    end;
           

[Shebuka]

try this

Code: [Select]

OpenDocument('"' + FileName + '"')

[IPguy]

Shebuka - thanks for the hint, but that did not change the behavior.
It still works on my systems and still does not work on my customer's system.
For now I'll stick with TProcess.

[BigChimp]

I wouldn't enclose the OpenDocument call with double quotes... AFAIK that's only necessary if calling things through the shell (e.g. CMD.exe) ...

In sysenvapis_win.inc, OpenDocument calls the ShellExecuteW API function, which should just call the registered handler for .pdf files. You confirmed the client can just double click a pdf file in explorer, so the handler must be set up correctly.

Things I'm thinking of (more thinking out loud):
- use of ANSI codepage vs UTF8: perhaps add a fileexistsutf8(DocFullFN) to check before calling OpenDocument?
- you're using a 32 bit compiler. Don't know if this has any impact on file associations; presumably calling explorer with tprocess starts 64 bit explorer. Don't think this should be a factor.

Have added a short test program with all methods.

With my Lazarus/FPC x86 (fairly recent snapshot) on Vista x64, OpenURL does nothing for me (but it doesn't return an error code either). Perhaps I'm doing something wrong there...
The other methods work.

[Shebuka]

I wouldn't enclose the OpenDocument call with double quotes... AFAIK that's only necessary if calling things through the shell (e.g. CMD.exe) ...

On Mac OS X the double quotes were essential to make it work, without, as soon as there was a space character in the path, it wasn't working. (and FileExist was returning true).

[BigChimp]

@Shebuka: thanks, didn't know that. Isn't that a bug?

Unfortunately, there doesn't seem to be any documentation for the function...

[Shebuka]

@Shebuka: thanks, didn't know that. Isn't that a bug?

Unfortunately, there doesn't seem to be any documentation for the function...

Don't know, maybe not, because even on shell you must enclose a path with spaces in double quotes, or if we see it from other prospective of code that "write once, compile everywhere" then the Darwin version of OpenDocument must double quote the path.

[BigChimp]

I agree quoting in shell is necessary, but that's another discussion.

Is quoting also necessary in e.g. FileExists or FileExistsUTF8? If that isn't necessary, I think this different behaviour in OpenDocument will need to be fixed.
Tested on Windows and quoting in OpenDocument is not necessary; I think "write once, compile anywhere" would instead suggest making quoting requirements the same: either require quotes on Windows, OSX and other platforms, or don't require them on any platform...

Edit: just tested it. FileExistsUTF8 works without double quoting. Double quoting the file leads to errors. So behaviour is not consistent between these functions.
Behaviour between Windows and OSX OpenDocument is also not consistent; I'm going to report a bug...

Edit2: bug 21651

[IPguy]

OK - I have a lot of responses to catch up on.  grin. 

re: openDocument - with or without double quotes - both worked on my windows systems; neither worked on my customers systems.  No errors, just did not open the file.

I do have a small test program for all three methods as well and can provide that if desired, but it sounds like BigChimp created his own.

I have encased the open methods with "if file exists" tests, but with my test program I'm opening pdf files in the same directory so that is not a concern.

[BigChimp]

One of my users is unable to open the .pdf help file my program points to.  Using the exact program, I'm not having any issues on any of my test systems.

Code: [Select]

...
DocFullFN := RimAppDir + PathDelim + DocFileName;
...
openURL(DocFullFN);


The documentation
http://lazarus-ccr.sourceforge.net/docs/lcl/lclintf/openurl.html
does suggest you need to prefix the URL with file://

In Lazarus code, I've also found this code (presumably for windows):

Code: [Select]

OpenURL('file://'+StringReplace(Filename,'\','/',[rfReplaceAll]));
... but which according to the docs mentioned above is actually not needed.

Edit:
this

Code: [Select]

OpenURL('file://'+PDFChooser.FileName)
fails while enclosing the call in double quotes (hi Shebuka works:

Code: [Select]

OpenURL('"file://'+PDFChooser.FileName+'"')

OpenURL on Windows calls shellexecute... that's presumably why specifying just the filename instead of the file:// URL works: Windows opens the application associated  with the file extension for you.
Presumably using the file:// URL would go through your default browser's MIME type register??

Still don't see why the double quotes are necessary... the parameter is defined in the MS Shellexecute help
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx
as:

A pointer to a null-terminated string that specifies the file or object on which to execute the specified verb.

(The verb used in this case is "open")

[BigChimp]

Related issues + patches in bug tracker (not too much progress there though):
http://bugs.freepascal.org/view.php?id=21659
http://bugs.freepascal.org/view.php?id=21659

[Bart]

Using the file:// URI schem to open (local) documents on Windows does not seem to have any advantage over using plain filename AFAICS.

Bart