Thank you.

>Doesn't really matter where you put it.
>
>However, if I remember right the ShellExecute API call never actually fails. It'll return an error code, but it will never actually fail by throwing an exception so the Try/Catch is pointless.
>
>You should check the result code from the API call and return that in your function then check the result value.
>
>But even that doesn't tell you much - that only tells you whether ShellExecute was able to parse your command line, not whether the actual invocation worked since the invocation is asynchronous and happens in the background.
>
>+++ Rick ---
>
>>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()?
>>
>>TIA