Zwei Windows Explorer starten und nebeneinander bildschirmfüllend positionieren

[Zacherl]

Zitat von FarAndBeyond:

Zitat:

Wozu die ganzen Try-Except-Blöcke, wenn sie doch leer sind?

Die sollen doch leer sein. Mein Motto lautet: Geht was schief, dann bitte alles in den ErrorLog... Kann der nicht erstellt werden, dann bitte gar nichts machen.
Wenn etwas nicht so läuft wie ich es erwarte, dann habe ich alles an einer Stelle im ErrorLog, sehe ich keinen, dann konnte er wohl nicht erstellt werden.

Das ist ja auch durchaus legitim, aber dazu reichen einige wenige Exception / Finally Blöcke. Außerdem umschließt du sehr viele Befehle mit Exception Blöcken, bei denen es unmgölich ist, dass überhaupt eine Exception auftritt.

Beim von Luckie schon angesprochenen kontraproduktivem Auslagern von FreeAndNil in eine extra Methode platzierst du beispielsweise einen leeren try..except Block, der niemals greifen kann. Deine StringList erzeugst du ja vorher schon in einem try..finally Resourcen-Schutzblock. Sprich: Die List ist auf jeden Fall erstellt, also kann Free gar nicht fehlschlagen. Dass FreeAndNil hier unnötigt ist, hat Luckie ja auch schon erwähnt. Konkret wäre dies die korrekte Herangehensweise:

Delphi-Quellcode:

SL := TStringList.Create;
try
  // ..
finally
  SL.Free; 
end;

Andere Stelle: EnumWindows. Darauf dass diese API eine Exception schmeißt, kannst du lange warten. Windows APIs besitzen einen Rückgabewert, der geprüft werden muss und schmeißen generell keine Exceptions (von seltenen CPU-Exceptions vielleicht mal abgesehen).

Dann sind an einigen Stellen die Resourcen-Schutzblöcke falsch positioniert. Die ErrorLogExists Funktion sollte beispielsweise eher so aussehen:

Delphi-Quellcode:

function ErrorLogExists: Boolean;
begin
  Result := false;
  if FileExists('ErrorLog.txt') then
  begin
    slLoad := TStringlist.Create;
    try
      slLoad.LoadFromFile('ErrorLog.txt');
      strErrorLog := slLoad.Text;
      Result := true;
    finally
      slLoad.Free;
    end;
  end;
end;

Also erst die StringList erzeugen und dann den Resourcen-Schutzblock mit try einleiten. Wichtig ist, dass das Create nicht mit im Block ist, sonst ist nicht garantiert, dass das Free im finally Block funktioniert.

Dieser Artikel könnte für dich auch noch interessant sein:
http://eurekalog.blogspot.de/2010/05...09-and_05.html

[FarAndBeyond]

@Zacherl:
Ja, du hast ja Recht....
Hab' die ganze Procedure neu gebaut und jetzt ist sie viel besser:

Delphi-Quellcode:

Procedure ErrorLog(ErrorInfo: String);
  Var
   slSave: TStringlist;
 Begin
  Try
   slSave:= TStringlist.Create;
    Try
     If FileExists('ErrorLog.txt')
     Then
      Begin
       Try
        slSave.LoadFromFile('ErrorLog.txt');
       Except
       End;
      End;

      slSave.Text:= DateTimeToStr(Now)+#13#10+
                    ErrorInfo+#13#10+
                    ''+#13#10+
                    slSave.Text;

      slSave.SaveToFile('ErrorLog.txt');
    Finally
     slSave.Free;
    End;
  Except
  End;
 End;

Natürlich ist da immer noch zu viel TryExceptEnd (was ich generell zu übertrieben benutze..) drin... ich brauche halt nur 'nen ErrorLog und möchte weiter nichts sehen...
Danke für die Info mit der Windows-Api... hab' nie groß darüber nachgedacht...

Warum ich das nicht gleich gesehen hab' weiß der Kuckuck...

EDIT:
Ok, das TryExceptEnd hinter Finally ist wirklich quatsch.... (Warum sollte es beim Speicherfreigeben Probleme geben... wahrscheinlich unwahrscheinlich ).
Der erste generelle TryExceptEnd-Block sichert das SaveToFile... (und das Erstellen der Stringlist, wenn ich auch nicht wüßte was da schiefgehen sollte..) hat also zumindest einen Sinn...

[bra]

Ich musste die eine (!) Routine jetzt zig mal durcharbeiten, um zu verstehen, was die überhaupt macht. Das ist ja vollkommen unübersichtlich mit den ganzen try...excepts.

[FarAndBeyond]

Das Ding ist doch völlig linear....

Nirgendwo steht geschrieben, dass du das auch so machen mußt... vielleicht mache ich es irgendwann anders...

[Erdbär]

Zitat von bra:

Ich musste die eine (!) Routine jetzt zig mal durcharbeiten, um zu verstehen, was die überhaupt macht. Das ist ja vollkommen unübersichtlich mit den ganzen try...excepts.

Delphi-Quellcode:

procedure ErrorLog(ErrorInfo: string);
var
  slSave: TStringlist;
  sLogFileName: string; // um Logdateinamen vorzugeben
begin
  sLogFileName := ChangeFileExt(paramstr(0), '.log');
  slSave := TStringlist.Create;

  if FileExists(sLogFileName) then slSave.LoadFromFile(sLogFileName);

  slSave.Text := DateTimeToStr(Now) + #13#10 +
    ErrorInfo + #13#10 + #13#10 + slSave.Text;

  try // Schreibrechte im Ordner vorhanden?
    slSave.SaveToFile(sLogFileName);
  except
    MessageBox(0, 'Cannot write to LogFile.', 'ERROR', mb_IconHand);
  end;

  slSave.Free;
end;

Ja, eins sollte reichen

[Luckie]

Und wo ist der Ressourcenschutzblock geblieben?

[Erdbär]

Was sollte da wie (und warum) geschützt werden?

[FarAndBeyond]

Zitat:

if FileExists(sLogFileName) then slSave.LoadFromFile(sLogFileName);

Beim Zugriff auf die Festplatte kann es zu zahlreichen Problemen kommen...

Neue externe Platten verwenden einen Sleep-Modus... ob das "FileExists" da ausreicht um die wachzurütteln???

Nur so ein Gedanke...

btw: Ich hab' bei EnumWindows versucht mit "If" abzufragen und D7 sagt mir "Incompatible Types"... Na ja, muß man ja auch nicht in diesem Fall, hatte mich nur gewundert da das bei "GetClassName" ja auch funzt (Prüfung auf <> 0).

@Erdbär:
Na das bei einer Exception die Stringlist trotzdem freigegeben wird !!!

[Erdbär]

Starte das Programm doch von einer "schlafenden" Festplatte, vielleicht wacht die HD schon dadurch auf?

[Luckie]

Zacherl hat doch in Beitrag http://www.delphipraxis.net/1342361-post39.html gezeigt, wie es geht.

PS: Warum hängst du den Qeulltext als Text-Datei an?