shellexecute hangs

[P.S.Bell]

I am using shellexecute which works each time it is called,
returns the file handle (ie not an error <=32) but doesnt allow
the application to close. In debug it pops up the CPU window,
allows some stepping but halts with a list of numbers as follows

8000024 ????
8000025 ????
8000026 etc

F9 does nothing and the form heading doesn't show the app as
running, but closing the app says it is in debug mode and it
cant be recompiled.

I am actually printing a pdf as follows:

nError:=shellexecute(0, 'print', Pchar('c:\temp\12345.pdf'),
nil, nil,SW_HIDE)

I have tried Peter Below's WinExecAndWait32V2 as follows but it
just fails returning -1

nError:=WinExecAndWait32V2( 'c:\temp\12345.pdf', SW_HIDE );

(or ftm putting the filename as a pchar)

Perhaps its sonething to do with Acrobat?

Pat Bell

[Peter Below (TeamB)]

In article <VA.000009a...@patbell.co.uk>, P.S.Bell wrote:
> I am using shellexecute which works each time it is called,
> returns the file handle (ie not an error <=32) but doesnt allow
> the application to close.

If you look at the task managers process list, is acrobat still
running? If you kill it, does your app come alive again?

>
> nError:=shellexecute(0, 'print', Pchar('c:\temp\12345.pdf'),
> nil, nil,SW_HIDE)
>
> I have tried Peter Below's WinExecAndWait32V2 as follows but it
> just fails returning -1

You cannot use CreateProcess to execute a data file. You would have to
find the program that handles the data file (i.e. Acrobat Reader) and
start that, passing it the proper command line to make it print the
file.

Which version of Acrobat Reader do you have installed? There was one
(the first 6.0 release i think) that had an annoying bug that left the
acrobat reader instance running after a PDF was printed with it from
another program. Try to uninstall it and get the lates version from
Adobe.

--
Peter Below (TeamB)
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be

[Rob Kennedy]

P.S.Bell wrote:
> I am actually printing a pdf as follows:
>
> nError:=shellexecute(0, 'print', Pchar('c:\temp\12345.pdf'),
> nil, nil,SW_HIDE)
>
>
> I have tried Peter Below's WinExecAndWait32V2 as follows but it
> just fails returning -1
>
> nError:=WinExecAndWait32V2( 'c:\temp\12345.pdf', SW_HIDE );
>
> (or ftm putting the filename as a pchar)
>
> Perhaps its sonething to do with Acrobat?

Yes, it's something to do with Acrobat. For some reason, Acrobat Reader
simply doesn't like to be started from within a program being debugged
by Delphi. Run your program outside the debugger, and I think you'll
find that your program runs correctly.

--
Rob

[P.S.Bell]

I have run it outside the debugger, and yes it didn't hang but now I get
multiple instances of AcroRd32.exe until the app seizes up. They don't
seem to be windows, but processes, so this is why I presumably can't find
them with hWndAdobe:=findwindow(nil,'Adobe Reader) which returns 0. Hence
I cant close them. What is worse they donut actually print anyway - every
line is run but the print job vanishes - I even check the printer name if
is going to via getprinter which is correct. I dont get this latter
behaviour on my own machine but I do get multiple acrord32.exes

This is making Delphi look pretty bad since the C# programmer can throw as
many pdfs as he likes via shellexecute (with equivalent parameters to my
Delphi rendition of the same Windows API function) with no problem. And
they print!

I am just using the Acrobat Reader so there are no settings to make.

I hate to do so but my only solution might be to get a C# routine
incorporating that shellexecute and passing a pdf from my delphi app. That
however somewhat admits defeat but I can't spend yet another week on this
problem. I have had several suggestions to use COM and DDE but I am loathe
to waste more time on increasingly complicated solutions when what I have
done so far should work and does in C# without recourse to anything more
sophisticated than shellexecute.

Pat Bell

[Eddie Shipman]

I think you are getting too frustrated and giving up too easily. And
your posting multiple questions on the same subject and not in the same
thread is really against group policy as Peter stated in your other
post.

>
> This is making Delphi look pretty bad since the C# programmer can throw as
> many pdfs as he likes via shellexecute (with equivalent parameters to my
> Delphi rendition of the same Windows API function) with no problem. And
> they print!
>

Well, personally, I don't see how he's doing it with a call like the
one you pointed out, using Printer,hDC as the hwnd parameter.

> I am just using the Acrobat Reader so there are no settings to make.
>
> I hate to do so but my only solution might be to get a C# routine
> incorporating that shellexecute and passing a pdf from my delphi app. That
> however somewhat admits defeat but I can't spend yet another week on this
> problem. I have had several suggestions to use COM and DDE but I am loathe
> to waste more time on increasingly complicated solutions when what I have
> done so far should work and does in C# without recourse to anything more
> sophisticated than shellexecute.

So what is so wrong with using COM like in my other post? I don't think
they are any more complicated.

If you are 100% sure that you don't want to do it that way, try this:

You will have to modify the path to the reader you are using.
The taskbar button for Acrobat reader does show for the time it is
printing even though I passed a SW_HIDE.

procedure PrintPDF
( AFileName: TFileName
);
function KillProcess(ProcessID: Integer): Boolean;
var
ExitCode : DWORD;
ProcessHandle: THandle;
begin
Result := False;
try
// Get a handle to the process with the required access rights
ProcessHandle := OpenProcess(PROCESS_TERMINATE, False, ProcessID);
if ProcessHandle <> 0 Then
Result := TerminateProcess(ProcessHandle, 0);
finally
CloseHandle(ProcessHandle);
end;
end;
var
CommandLine: String;
Security : TSecurityAttributes;
start : TStartUpInfo;
ProcessInfo : TProcessInformation;
Apprunning : DWord;
begin
CommandLine :=
'"C:\Program Files\Adobe\Acrobat 7.0\Reader\AcroRd32.exe"' +
' /p /h "' + AFileName + '"';
with Security do
begin
nlength := SizeOf(TSecurityAttributes);
binherithandle := true;
lpsecuritydescriptor := nil;
end;
FillChar(Start,Sizeof(Start),#0);
start.dwFlags := STARTF_USESHOWWINDOW;
Start.wShowWindow := SW_HIDE;
if CreateProcess(nil,
PChar(CommandLine),
@Security,
@Security,
true,
NORMAL_PRIORITY_CLASS,
nil,
nil,
start,
ProcessInfo)
then
begin
repeat
Apprunning := WaitForSingleObject(ProcessInfo.hProcess,100);
// required for the app to actually run
Sleep(1000);
Application.ProcessMessages;
until ((Apprunning <> WAIT_TIMEOUT) or (Apprunning <> WAIT_FAILED));
if Apprunning <> WAIT_FAILED then
begin
Application.ProcessMessages;
end;
end;
KillProcess(ProcessInfo.dwProcessId);
CloseHandle(ProcessInfo.hProcess);
CloseHandle(ProcessInfo.hThread);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
PrintPDF('c:\remove.pdf');
end;

[P.S.Bell]

I ran the code and nothing happened (well ran through all the print code but
nothing printed) until I increased the waitforsingleobject timout to 10000 it
worked fine - when run as a console app but not as a process. Finally, as a
random guess, I checked the security settings for the printer, although
'Everyone' had rights to print, I added administrator... now it all prints. So
security checks must be more stringent when running processes rather than
console apps.

Windows eh?

I In article <MPG.1df914ae2...@forums.borland.com>, Eddie Shipman
wrote:

Pat Bell