Quickreport und Windows-Pdf-Printer

[FrankJ28]

Hallo in die Runde,
hat jemand eine Idee, wie ich einem Quickreport bei der Ausgabe über den Windows PDF-Printer den Dateinamen mitgeben kann?
Vielen Dank
Frank

[tshubaka]

Hallo
ich mache das so.

Delphi-Quellcode:

  DateiName := EPANr.Text +'_'+ EdArtikelnummer.Text +'_'+ FMesswerkzeug.ESerieNr.Text +'.pdf';
  DateiName := CheckCharsInString(['\','/',':','?','"','<','>','|','*'], '_', DateiName);
  SavePDF.FileName := DateiName;
  if SavePDF.Execute then
  begin
    expFilt := TQRPDFDocumentFilter.create(SavePDF.FileName);

Gruss

[Achim Kalwa]

Zitat:

Zitat von FrankJ28 (Beitrag 1478297)

hat jemand eine Idee, wie ich einem Quickreport bei der Ausgabe über den Windows PDF-Printer den Dateinamen mitgeben kann?

Ich vermute mal, Du willst den Drucker "Microsoft Print to PDF" per QuickRep.Print() nutzen, ohne den von tshubaka erwähnten QRExport-Filter.

Ohne tiefe Eingriffe in den Code von QuickReport wird das kaum möglich sein. Das Windows-API bietet zwar eine Möglichkeit, den Ausgabe-Dateinamen beim Start des Druckjobs mitzugeben, aber leider ist dies in Vcl.Printers.pas so verkapselt, dass man da nicht dran kommt:

Code:

procedure TPrinter.BeginDoc;
var
  DocInfo : TDocInfo; 
begin
...
  FillChar(DocInfo, SizeOf(DocInfo), 0);
  with DocInfo do
  begin
    cbSize := SizeOf(DocInfo);
    lpszDocName := PChar(Title);
    lpszOutput  := PChar(OutFileName); // diese neue Zeile wäre erforderlich!
  end;
...
  if StartDoc(DC, DocInfo) <= 0 then...

TPrinter.BeginDoc() ist leider nicht virtuell, kann also nicht mit eigenem Code überschrieben werden. Es gibt seit Jahren einen QP-Eintrag zu diesem Thema, aber da passiert nix:RSP-13430. Mein Vorschlag wäre entweder ein Property "OutFileName" einzubauen, oder ein OnBeginDoc-Event, in welchem man den DocInfo-Record nochmal anpassen kann.

Ein anderer Weg ist hier beschrieben:

Code:

var
  DeviceMode: THandle;
  Device, Driver, Port: array[0..80] of Char;
begin
  Printer.PrinterIndex := Printer.Printers.IndexOf('Microsoft Print to PDF');
  Printer.GetPrinter(Device, Driver, Port, DeviceMode);
  Printer.SetPrinter(Device, Driver, 'C:\Temp\Test.pdf', 0);

  Printer.BeginDoc;
  Printer.Canvas.TextOut(100, 100, 'Test');
  Printer.EndDoc;
end;

Aber QuickReport versteckt die Verwendung von TPrinter in seiner eigenen Klasse TQRPrinter, also müsste man das auch aufbohren.

[FrankJ28]

Hallo und vielen Dank an euch.
Da der QR in QRPRNTR bei Druckerwechsel jeweils ein eigenes GetPrinter, SetPrinter durchführt löse ich das durch Setzen des gewünschten PDF-Names in der aufrufenden Routine. Dort wechsle ich ja auch automatisch auf den PDF-Printer.

Code:

Printer.PrinterIndex := Printer.Printers.IndexOf('Microsoft Print to PDF'); // MS PDF-Drucker
Printer.Title:='xyz.pdf'; // der gewünschte Dateiname

In der Unit QRPRNTR habe ich dann die Prozedur ResetDriver aufgeschlaut und schaue, ob ein Pdf erzeugt werden soll. Wenn ja, dann setze ich den Port eben mit diesen Dateinamen.

Code:

procedure ResetDriver(aPrinter : TPrinter);
var
  Device, Name, Port: array[0..MAX_PATH] of Char;
  DevMode: THandle;
begin
  aPrinter.GetPrinter( Device, Name, Port , DevMode );
  if Pos('.pdf',aPrinter.Title)>0
     then aPrinter.SetPrinter( Device, Name, PWideChar(aPrinter.Title) , 0 )
     else aPrinter.SetPrinter( Device, Name, Port , 0 );    // 12/02/16
end;

Danke und ciao

Frank

[BlueStarHH]

Danke, das nutze ich auch so um PDFs mit Quickreport zu erstellen. Das Problem ist jetzt nur: Woher weiß ich, wann der PDF-Drucker fertig ist? Ich möchte die PDF-Datei per Schalterklick erstellen und dann auf ein Netzlaufwerk kopieren. Dazu muss sie vollständig erstellt sein.

[FrankJ28]

Hi,
in der Tat habe ich das Problem "wann fertig" auch noch nicht gelöst. Was spricht in deinem Fall gegen den Dateinamen inklusive Netzwerkpfad?
Ciao
Frank

[BlueStarHH]

Zitat:

Zitat von FrankJ28 (Beitrag 1498741)

in der Tat habe ich das Problem "wann fertig" auch noch nicht gelöst. Was spricht in deinem Fall gegen den Dateinamen inklusive Netzwerkpfad?

Im Netzwerkpfad dürfen nur vollständige Dateien liegen, weil noch mehr damit gemacht wird. Der Ordner wird überwacht. Ist dort eine neue Datei, wird sie automatisch ins DMS importiert. Das soll und kann nur mit fertigen Dateien passieren.

[BerndS]

Könnte man nicht testen, ob sich die Datei exklusiv (fmOpenRead or fmShareExclusive) öffnen lässt?
Wenn die noch offen zum Schreiben ist, sollte das dann einen Fehler erzeugen.
ein kleines Beispiel: (Datei muss aber vorhanden sein)

Delphi-Quellcode:

function FileNotOpen(AFileName: string): Boolean;
begin
  try
    TFileStream.Create(AFileName, fmOpenRead or fmShareExclusive).Free; 
    Result := True;
  except
    Result := False;
  end;
end;

[BlueStarHH]

Zitat:

Zitat von BerndS (Beitrag 1498750)

Könnte man nicht testen, ob sich die Datei exklusiv (fmOpenRead or fmShareExclusive) öffnen lässt?

Danke, das könnte ein guter Ansatz sein. Ich teste das mal.

[FrankJ28]

Zitat:

Zitat von BlueStarHH (Beitrag 1498742)

Zitat:

Zitat von FrankJ28 (Beitrag 1498741)

in der Tat habe ich das Problem "wann fertig" auch noch nicht gelöst. Was spricht in deinem Fall gegen den Dateinamen inklusive Netzwerkpfad?

Im Netzwerkpfad dürfen nur vollständige Dateien liegen, weil noch mehr damit gemacht wird. Der Ordner wird überwacht. Ist dort eine neue Datei, wird sie automatisch ins DMS importiert. Das soll und kann nur mit fertigen Dateien passieren.

Hi,
dann hast Du doch das gleiche Problem, wenn Du die Datei auf das Netzwerklaufwerk kopierts. Die ist ja nun auch nicht "schwupps da".
Ciao
Frank