ParamStr komplette Verzeichnisse auswählen

[GroZ]

Hey, Ich hoffe mir kann jemand helfen. Mein Konsolenkonvertierer (FRP-PDF) ist soweit fertig. Ich kann aber derzeit nur einzelne Dateien umwandeln. Ich möchte aber Verzeichnisse, Ordner und Verzeichnisse + Unterordner konvertieren können. zum beispiel so: C:\Alte Dateien\FRP /DSub -> Dann soll er das komplette Verzeichnis konvertieren mit Unterordnern. Wie stell ich das am besten an?
Hier mein Code:

Delphi-Quellcode:

program Project2;

uses
  Forms, ShellApi, SysUtils, Graphics, Math,
   frxClass, frxExportPDF, FR_Class, PsFR_E_Main, PsFR_E_PDF;

{$AppType Console}
function FRPtoPDF(AFRPFile, APDFFile : string) : integer;
var
  frReport : TfrReport;
  PDFExport : TPsfrPDFExport;
begin
 Result := 1;
 if not fileexists(AFRPFile) then
  exit;
 if fileexists(APDFFile) then
  begin
    if not DeleteFile(APDFFile) then
     begin
      Result := 2;
      exit;
     end;
  end;


  frReport := TfrReport.Create(NIL);
  PDFExport := TPsfrPDFExport.Create(NIL);
  try
   PDFExport.ShowDialog := false;
   frReport.ShowProgress := false;
    try
     frReport.LoadPreparedReport(AFRPFile);
     frReport.ExportTo(PDFExport, APDFFile);
    except
     Result := 3;
     exit;
    end;


  finally
   PDFExport.Free;
   frReport.Free;

  end;
 Result := 0;
end;

var
  f : integer;
  eingabe : string;
begin
  Writeln(Paramstr(1));
  Writeln('////////////');     //unnötig
  f := FRPtoPDF(Paramstr(1),ChangeFileExt(Paramstr(1),'.pdf'));

   if f = 0 then
    Writeln('Konvertierung erfolgreich')
   else
    begin
     Writeln('Ein Fehler ist aufgetreten '+ IntToStr(F));
     Writeln('Geben sie /? ein fuer weitere Informationen');
    end;
  readln(eingabe); // Wegnehmen wenn fertig
  if eingabe = '/?' then
  begin
   Writeln('Fehlercode 1 - Verzeichnis existiert nicht oder ist falsch');
   Writeln('Fehlercode 2 - PDF wurde ersetzt');
   Writeln('Fehlercode 3 - Konvertierung fehlgeschlagen');
   Writeln('D= - Directory - Verzeichnis');
   Writeln('D= / Sub - Verzeichnis mit Unterordnern');
   Writeln('F= - File - Ordner');
   readln; // Wegnehmen wenn fertig
  end;

end.

[baumina]

Schau dir mal dieses Tutorial an.

[mm1256]

Hallo,

wie man die Commandline auswertet habe ich dir im anderen Thread schon gezeigt. Dazu noch der Link von Baumina, und du bist am Ziel.

Zu deinem Code. Schau dir auch nochmal den Try..Finally-Block an. Wenn du zwei constructoren aufrufst, dann solltest du diese besser innerhalb des try aufrufen.

Delphi-Quellcode:

try
  frReport := TfrReport.Create(NIL);
  PDFExport := TPsfrPDFExport.Create(NIL);
finylly
  PDFExport.Free;
  frReport.Free;
end;

Hintergrund: Wenn einer der beiden constructoren fehlschlägt, wird in jedem Fall mit Free wieder richtig aufgeräumt, weil Free auf "nil" prüft, und somit auch keine Exception wirft, wenn eine der beiden Instanzen nil ist.

[GroZ]

Okay ich werd es mal probieren. Danke

[Der schöne Günther]

Zitat:

Zitat von mm1256 (Beitrag 1319410)

Hintergrund: Wenn einer der beiden constructoren fehlschlägt, wird in jedem Fall mit Free wieder richtig aufgeräumt, weil Free auf "nil" prüft, und somit auch keine Exception wirft, wenn eine der beiden Instanzen nil ist.

Die Absicht ist richtig (Konstruktor vor dem try..finally-Block), die Begründung aber nicht :warn:

Wenn im Konstruktor eine Exception auftritt
- Wird der Destruktor ausgeführt
- Und die Exception anschließend weiter geworfen
- In den try..finally-Block kommt man somit erst gar nicht.


(Deshalb ist

Delphi-Quellcode:

Free()

sogar eigentlich unnötig da im try..finally-Block die Referenz niemals

Delphi-Quellcode:

nil

sein kann, ein

Delphi-Quellcode:

Destroy()

reicht völlig)

[Sir Rufo]

ts, ts, ts, ...

Delphi-Quellcode:

procedure dofoo;
var
  foo: TFoo;
begin
  foo := TFoo.Create;
  try

    // work with foo

  finally
    foo.Free;
  end;
end;

// aber

procedure dofoobar;
var
  foo: TFoo;
  bar: TBar;
begin
  // lokale Variablen sind NICHT initialisiert, 
  // also machen wir das mal
  foo := nil;
  bar := nil;
  try
    foo := TFoo.Create;
    bar := TBar.Create;
    
    // work with foo and bar

  finally
    foo.Free;
    bar.Free;
  end;
end;

[GroZ]

Was ist ein TFoo? Konnte dazu in der OH nix finden..

[p80286]

Zitat:

Zitat von GroZ (Beitrag 1319419)

Was ist ein TFoo? Konnte dazu in der OH nix finden..

das ist nur ein Platzhalter für einen nicht konkreten Typ so wie "TIrgendwas"

@sirRufo Was will uns der Dichter damit sagen?

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1319421)

@sirRufo Was will uns der Dichter damit sagen?

Das war eine Antwort auf die Beiträge:

Zitat:

Zitat von mm1256 (Beitrag 1319410)

Zu deinem Code. Schau dir auch nochmal den Try..Finally-Block an. Wenn du zwei constructoren aufrufst, dann solltest du diese besser innerhalb des try aufrufen.

Delphi-Quellcode:

try
  frReport := TfrReport.Create(NIL);
  PDFExport := TPsfrPDFExport.Create(NIL);
finylly
  PDFExport.Free;
  frReport.Free;
end;

Hintergrund: Wenn einer der beiden constructoren fehlschlägt, wird in jedem Fall mit Free wieder richtig aufgeräumt, weil Free auf "nil" prüft, und somit auch keine Exception wirft, wenn eine der beiden Instanzen nil ist.

und

Zitat:

Zitat von Der schöne Günther (Beitrag 1319417)

Zitat:

Zitat von mm1256 (Beitrag 1319410)

Hintergrund: Wenn einer der beiden constructoren fehlschlägt, wird in jedem Fall mit Free wieder richtig aufgeräumt, weil Free auf "nil" prüft, und somit auch keine Exception wirft, wenn eine der beiden Instanzen nil ist.

Die Absicht ist richtig (Konstruktor vor dem try..finally-Block), die Begründung aber nicht :warn:

Wenn im Konstruktor eine Exception auftritt
- Wird der Destruktor ausgeführt
- Und die Exception anschließend weiter geworfen
- In den try..finally-Block kommt man somit erst gar nicht.


(Deshalb ist

Delphi-Quellcode:

Free()

sogar eigentlich unnötig da im try..finally-Block die Referenz niemals

Delphi-Quellcode:

nil

sein kann, ein

Delphi-Quellcode:

Destroy()

reicht völlig)

Denn zum echten Schutz vor einem MemLeak müsste es so lauten

Delphi-Quellcode:

frReport := nil;
PDFExport := nil;
try
  frReport := TfrReport.Create(NIL);
  PDFExport := TPsfrPDFExport.Create(NIL);
finally
  PDFExport.Free;
  frReport.Free;
end;

[Olli73]

Zitat:

Zitat von p80286 (Beitrag 1319421)

@sirRufo Was will uns der Dichter damit sagen?

Ich bin zwar nicht Sir Rufo, antworte aber trotzdem mal...

Es geht darum, ein

Delphi-Quellcode:

procedure dofoobar;
var
   foo: TFoo;
   bar: TBar;
begin
   foo := TFoo.Create;
   try
     bar := TBar.Create;
     try
      // work with foo and bar
     finally
       bar.Free;   
     end;
   finally
     foo.Free;
   end;
end;

zu vereinfachen (= weniger Einrückungen/Verschachtelungen).

Das Thema hatten wir schon mal.

Edit: Zu spät. (Aber kein blauer Balken?!)

[mm1256]

Ja genau, um diese Vereinfachung geht es.

@Sir Rufo, ich sehe wir sind uns einig was den try..finally anbelangt. Wo ich mir nicht ganz sicher bin, warum

Delphi-Quellcode:

frReport := nil;
PDFExport := nil;

Vorsichtsmaßnahme, oder Pflichtübung. Wenn Pflichtübung, warum? Meine Ansicht bzw. Wissensstand: Es sind lokale Instanzen und darum müsste doch die nil-Zuweisung eigentlich nicht erforderlich sein. Anders sieht es aus, wenn es globale oder Formvariablen sind, weil dann der Zeiger auf irgendwas zeigen kann, was vorher schon mal in Benutzung war und noch nicht überschrieben ist.

[Sir Rufo]

Zitat:

Zitat von mm1256 (Beitrag 1319427)

@Sir Rufo, ich sehe wir sind uns einig was den try..finally anbelangt. Wo ich mir nicht ganz sicher bin, warum

Delphi-Quellcode:

frReport := nil;
PDFExport := nil;

Vorsichtsmaßnahme, oder Pflichtübung. Wenn Pflichtübung, warum? Meine Ansicht bzw. Wissensstand: Es sind lokale Instanzen und darum müsste doch die nil-Zuweisung eigentlich nicht erforderlich sein. Anders sieht es aus, wenn es globale oder Formvariablen sind, weil dann der Zeiger auf irgendwas zeigen kann, was vorher schon mal in Benutzung war und noch nicht überschrieben ist.

Das liegt daran, dass lokale Variablen nicht automatisch initialisiert werden. Da kann sonst was drin stehen ...

Wenn ich also sicher gehen will, das dort der Wert xy drin steht, dann muss ich diesen Wert aktiv zuweisen.

[mm1256]

Zitat:

Zitat von Sir Rufo (Beitrag 1319429)

Das liegt daran, dass lokale Variablen nicht automatisch initialisiert werden. Da kann sonst was drin stehen ...

Wenn ich also sicher gehen will, das dort der Wert xy drin steht, dann muss ich diesen Wert aktiv zuweisen.

Danke, wieder was gelernt...und natürlich auch überprüft. Stimmt :thumb:

[DeddyH]

Hier hatte ich das auch schon einmal durchexerziert: http://forum.delphi-treff.de/index.p...verschachteln/