VFP 6.0 ShellExecute on 64 Bit Server 1

[Auguy]

I have a VFP 6.0 app that has been moved to a Win 2008 R2 Standrad SP1 64 Bit server. The program runs fine on the server, but the ShellExecute doesn't open any PDF files. I don't get any errors or warnings, it just doesn't open the PDF. I can go to the folder the PDF file is in and dbl-click it and the file opens in Adobe Reader X. The app will open a .txt file in notepad using this code. The network tech has Adobe Acrobat 8.1 and Adobe Reader Reader X 10.1 installed. The PDF files have the Adobe Reader Reader X set as the default program. Do you think this is an Adobe setup problem, or do I have to change how I call the ShellExecute to get this to work?

DECLARE INTEGER ShellExecute ;
	IN SHELL32.DLL ;
	INTEGER nWinHandle,;
	STRING cOperation,; 
	STRING cFullFileName,;
	STRING cParameters,;
	STRING cDirectory,;
	INTEGER nShowWindow

ShellExecute(0, "open", cFullFileName, "", "", 1)

cFullFileName is the full path to the PDF file.


Auguy
Sylvania/Toledo Ohio

 

[Olaf Doschke]

I have about the same setup: Win7 (64bit), Adobe Reader X 10.1.2 (32 bit)

Your code works for me and opens Adobe, when using a fullfilename of a PDF file.

My Adobe Reader is 32bit, but I also ShellExecuted to start Treucrypt (64bit) by "open"ing a tc (true crypt container) file and that works.

So I assume it's an Adobe Reader issue, though I have no idea what to check, as you say double clicking PDF files opens them in Adobe, that means the file extension is setup to launch Adobe Reader by the "open" operation.

Bye, Olaf.

 

[Auguy]

I'm guessing the Adobe Reader X is 64 bit. Do you think we need to install a 32 bit version?

Auguy
Sylvania/Toledo Ohio

 

[Olaf Doschke]

No, from my experience with TrueCrypt as a 64bit application, this doens't matter.

Also wh guessing? Is it installed in "Program Files (x86)" or "Program Files"?

Try reinstalling.

Bye, Olaf.

 

[Olaf Doschke]

Oh, and try the obvious: move pdf files somewhere else and retry. Shorter path perhaps, and somewhere everyone can read/write.

Also check ShellExecute output and GetLastError output.

? ShellExecute(...)
DECLARE INTEGER GetLastError IN kernel32
? GetLastError()

See what ShellExecute returns and then what error number you get from GetLastError and compare with the SE_ERR constants:

#define SE_ERR_FNF 2
#define SE_ERR_PNF 3
#define SE_ERR_ACCESSDENIED 5
#define SE_ERR_OOM 8
#define SE_ERR_DLLNOTFOUND 32

#define SE_ERR_SHARE 26
#define SE_ERR_ASSOCINCOMPLETE 27
#define SE_ERR_DDETIMEOUT 28
#define SE_ERR_DDEFAIL 29
#define SE_ERR_DDEBUSY 30
#define SE_ERR_NOASSOC 31

Bye, Olaf.

 

[Auguy]

Thanks Olaf, I will see if I can get the error.

Auguy
Sylvania/Toledo Ohio

 

[Auguy]

I get Error # 2 which is file not found I assume. I don't know why it can't find the file. I display a list of files that I built from reading the folder and then let the user pick the file. I'm using a mapped drive letter in the full path name of the file, maybe it wants the UNC path.

Auguy
Sylvania/Toledo Ohio

 

[Olaf Doschke]

Double backslash perhaps? Or something like that?

How long is the path? You might be exceeding a length. ShellExecute may trigger a DDE Execute of a commandline with adobe.exe and the pdf filename as parameter and that parameter might be too long, is truncated and then the file not found results from that.

Try to put the PDFs somewhere else, as said.

If the problem persists with short paths, take a precise look at the file name you build from the path and the user pick. Maybe trailing spaces???

GetFile() will return fullpath + filename correctly. How do you let the user pick a file? ADIR()? It just returns the file name, not including the path.

Bye, Olaf.

 

[Auguy]

Thanks for all of your help Olaf.

The program will open Excel files in Excel and .txt files in Notepad as expected.

I let the users pick the files from a TreeView I build.

No double backslash or trailing spaces in file names.

I tested shorter paths.

I hard coded a filename.

I tested using the network path name (\\server\...) instead of the mapped drive.

I tested files on drive C to see if it didn't like the mapped drive.

I tried GetFile().

No success I always get Error # 2. I'm still thinking this is Adobe problem.



Auguy
Sylvania/Toledo Ohio

 

[Olaf Doschke]

Yes, then it seems an adobe problem. The only other way a file existing is regarded as not found is because of insufficient rights to read, being in a hidden folder or the name being valid on another computer, but not locally. I doubt the latter is the case, as you tested Getfile() and run Shellexecute local, the name would be valid.

Is Adobe picky on the case of the file name, perhaps? SOME.PDF vs some.pdf or Some.PDF or whatever the capitalistion on disc is.

Bye, Olaf.