>Hi,
>
>I have a program/routine in my application which prints a file, using ShellExecute (most of the times the printed file is a PDF). So, the application using Adobe Reader - or whatever is set on the user desktop - to print the document.
>
>Sometime there is a problem. If a user does not put in the file name correctly. Or the file has some "odd" characters. So, the printing does not work.
>
>I was checking this and found that my program does not have TRY CATCH around ShellExecute. So I am wondering what is a better practice as far as putting the TRY CATCH. Here is how it works:
>
>First, the program determines the document to be printed and then has this code:
>

>=CallShellExecute( "print", ALLTRIM(tcDocumentName), 0, "", "", tlDoNotShowErrMsg )
>

>
>The function CallShellExecure which is actually print. Example:
>

>	DECLARE INTEGER ShellExecute IN "Shell32.dll" ;
>	    INTEGER hwnd, ;
>	    STRING lpVerb, ;
>	    STRING lpFile, ;
>	    STRING lpParameters, ;
>	    STRING lpDirectory, ;
>	    LONG nShowCmd
>
>          lnResult =Shellexecute(0, tcCommand, tcFileName, tcParameter,tcDirectory,tnShowCommand)
>

>
>My question is, is it better to wrap the actual ShellExecute() with TRY CATCH or the calling function CallShellExecute()?
>


Doug Hennig published a wrapper for ShellExecute called ExecuteFile. It handles all the details and simply returns the value that ShellExecute returns, so you can test whether it was successful or not. I don't remember which of his articles it came from, but it's included (with his permission) in the materials for my session from Virtual Fox Fest.

Tamar