Adobe Acrobat via OLE oder Alternativen

[Jumpy]

Hallo,

ein altes Programm öffnet und druckt PDF-Dokumente via OLE-Automation von AdobeAcrobat 8.

Aus bestimmten Gründen reicht(e) der Reader damals nicht aus. Es gab da u.a. Probleme mit der Druckreihenfolge bei mehreren Dokumenten hintereinander auf Windows Vista und höher (bei Verwendung des Readers via ShellExecute zum ausdrucken).
Hier herrscht die Meinung vor, das ShellExecute ja quasi eine Fire and Forget Operation ist, wo dann evtl. der Reader ein großes Dokument öffnet, während schon ein zweites ShellExecute abgeschossen wird mit einem kleineren Dokument, das parallel schneller geöffnet und zum Drucker gesendet wird und schon ist die Druckreihenfolge durcheinander. Könnte das sein?

Das Problem ist, dass nun PDF-Dokumente verarbeitet werden müssen, mit denen Acrobat 8 nicht mehr zu recht kommt, so dass nun mehrere Optionen im Raum stehen:

- aktuellen Akrobat kaufen -> Frage: Reicht da für OLE Standard oder braucht man Professionel, weiß da wer was? In der SDK steht nur das OLE mit dem Reader nicht geht, aber heißt das wirklich das im Umkehrschluss Acrobat Standard und Professional beide gehen?

- PDF mit einer TWebbrowser-Komponente öffnen. Kann man da dann den Druck anstoßen? Wie das mit der Druckreihenfolge aussieht müsste dann noch getestet werden.

- Irgendeine PDF-Komponete für Delphi? Kann da jemand was empfehlen, was mit aktuellen PDFs zu recht kommt und günstiger ist als Adobe Acrobat.

- Gäbe es weitere Optionen?

[hathor]

Print a PDF file with dialog: AcroRd32.exe /P PdfFile
Print a PDF file silently: AcroRd32.exe /N /T PdfFile PrinterName [ PrinterDriver [ PrinterPort ] ]

Hinzugefügt:
Open a PDF file in a new instance of Adobe Reader: AcroRd32.exe /N PdfFile

Delphi-Quellcode:

procedure TForm1.ButtonClick(Sender: TObject); //PRINT
var fn : String;
begin
fn:=ExtractFilePath(ParamStr(0)) +'test-1.pdf';
ShellExecute(0, 'open','acrord32', PChar('/p /h ' + fn), nil, SW_HIDE);
end;

[Jumpy]

@hathor:

Das ist die Methode die bei vielfachen PDF's hintereinander nicht sauber funktioniert und die Druckreihenfolge verwurstelt, es sei denn einer der genannten Parameter verhindert das irgendwie?

[Olli73]

Ich würde einfach anstatt ShellExecute() CreateProcess() verwenden. Dann kannst du warten, bis ein Dokument ausgedruckt ist und danach das nächste drucken.

Funktioniert dann zwar nicht "parallel", aber da der Drucker der limitierende Faktor sein dürfte, macht das nicht so viel aus.

Den gesamten Druckprozess kann man ja in einen Thread oder Prozess auslagern, damit man mit der Oberfläche weiterarbeiten kann.


Gruß,
Olli

[p80286]

Wie wäre es denn mit einer Batchdatei?
Wenn ich mich richtig erinnere sollte die alles so machen wie Du es gerne hättest.

U.U können Dir die Dateien im Anhang weiter helfen.
(c) by EuPatentamt

Gruß
K-H

[mkinzler]

Zitat:

Zitat von Olli73 (Beitrag 1264418)

Ich würde einfach anstatt ShellExecute() CreateProcess() verwenden. Dann kannst du warten, bis ein Dokument ausgedruckt ist und danach das nächste drucken.

Funktioniert dann zwar nicht "parallel", aber da der Drucker der limitierende Faktor sein dürfte, macht das nicht so viel aus.

Den gesamten Druckprozess kann man ja in einen Thread oder Prozess auslagern, damit man mit der Oberfläche weiterarbeiten kann.


Gruß,
Olli

Oder WaitForSingleObject()

[himitsu]

Zitat:

Zitat von Jumpy (Beitrag 1264391)

Hier herrscht die Meinung vor, das ShellExecute ja quasi eine Fire and Forget Operation ist, wo dann evtl. der Reader ein großes Dokument öffnet, während schon ein zweites ShellExecute abgeschossen wird mit einem kleineren Dokument, das parallel schneller geöffnet und zum Drucker gesendet wird und schon ist die Druckreihenfolge durcheinander. Könnte das sein?

Jupp,

aber teilweise kann man auch warten.
ShellExecAndWait, bzw. CreateProcess

Das kommt aber auf das gestartete Programm drauf an. Wenn man z.B. einen Launcher wartet, der wiederum einen weiteren Prozess startet, bzw. die Daten nur übergibt, und sich dann beendet, dann kommt das natürlich auch wieder "vorzeitig" zurück ... wobei der Launcher natürlich wirklich fertig ist. :stupid:
Natürlich kann man dann auch nicht sowas wie

Delphi-Quellcode:

ShellExecuteXXX(0, 'print', 'my.pdf', ...)

machen, sondern muß sich schon direkt an das "richtige" Programm wenden.


Lokal könnte man auch versuchen die Druckerwarteschlange zu überwachen und sendet den nächsten Druckauftrag erst dann ab, wenn der Letzte durch ist.
Oder man überwachte die Acrobat-Instanzen und startet den nächsten Druck, wenn keine Instanz mehr aktiv ist, die aktuell etwas drucken soll.
Oder ...

[hathor]

Zitat:

Zitat von Jumpy (Beitrag 1264404)

@hathor:

Das ist die Methode die bei vielfachen PDF's hintereinander nicht sauber funktioniert und die Druckreihenfolge verwurstelt, es sei denn einer der genannten Parameter verhindert das irgendwie?

Es wird doch nur EINE Instanz geöffnet.
Mehrere Instanzen bekommt man mit dem Befehl:

Open a PDF file in a new instance of Adobe Reader: AcroRd32.exe /N PdfFile

[Jumpy]

Zitat:

Zitat von hathor (Beitrag 1264431)

Zitat:

Zitat von Jumpy (Beitrag 1264404)

@hathor:

Das ist die Methode die bei vielfachen PDF's hintereinander nicht sauber funktioniert und die Druckreihenfolge verwurstelt, es sei denn einer der genannten Parameter verhindert das irgendwie?

Es wird doch nur EINE Instanz geöffnet.
Mehrere Instanzen bekommt man mit dem Befehl:

Open a PDF file in a new instance of Adobe Reader: AcroRd32.exe /N PdfFile

OK. Was passiert denn dann wenn ich 10x schnell hintereinander ShellExecute aufrufe? Geht das immer an die selbe (ggf. vom ersten Aufruf noch offene) Reader-Instanz? Und was passiert dann da, wenn die noch nicht mit dem Drucken fertig ist.
Ich kann den Vorgang halt nicht genau erklären, aber die Druckreihenfolge kann durcheinander kommen.

---------

Die anderen Aufruf-Vorschläge mit CreateProcess und ShellExecWait werde ich mal probieren, ob das da mit dem Timing besser hinkommt.
Reader-Prozess überwachen und erst den nächsten Druck starten wenn keine mehr da ist, könnte problematisch werden, wenn irgendwo in einer anderen Instanz noch ein Dokument offen ist, weil der User das so wollte, wäre also eher die Notlösung. Ebenso Spooler-Überwachung.

Danke für die Anregungen. Werde das mal an die Kollegen weiterleiten und mich dann in den Urlaub verabschieden.