>>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
Thank you.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham