XP Usermanagers 6.1 Open Source

[nahpets]

Schau bitte mal alle eingebundenen Units durch, ob da irgendwo ein {$D-} zu finden ist, dann werden dort die Debuginfos wieder ausgeschaltet.

Ist ein leidiges Problem, das ich von Delphi 7 kenne.

[Delphi-Laie]

Zitat von nahpets:

Schau bitte mal alle eingebundenen Units durch, ob da irgendwo ein {$D-} zu finden ist, dann werden dort die Debuginfos wieder ausgeschaltet.

Ist ein leidiges Problem, das ich von Delphi 7 kenne.

Danke, Stephan!

Das war es zwar auch nicht, aber Du brachtest mich auf die richtige Fährte: Es liegt an der eingebundenen bzw. konkret aufgerufenen

{$I CompilerSwitches.inc}

Diese entfernt bzw. auskommentiert, und schon sind die Haltepunkte da!

[Delphi-Laie]

So, einen ersten kleinen Fehler habe ich entdeckt. Klein bezieht sich nicht auf seine Folge - immerhin beendet sich das Programm dann selbst bzw. wird von Windows beendet, allerdings ohne weiteren Schaden - sondern die Wahrscheinlichkeit seines Auftretens.

Wird dem Programm unter Extras -> Benutzer importieren eine ungültige XML-Datei angeboten, endet das Programm mit "Usermanager.exe hat ein Problem festgestellt und muss beendet werden." und danach mit "Exception Exception in Modul Usermanager.exe bei 0001BB90". Das passiert, wenn das Programm separat gestartet wird. Wird es aus der IDE heraus gestartet, kommt hingegen "Runtime Error 217 at 00011F07".

Der Fehler passiert in der Funktion "ImportXMLThread" und erstaunt mich insofern, als daß dort doch mit "try..finally" ihm entgegengewirkt wird.

Lange Rede, diesen try-Block mit einem weiteren try..except umhüllt, also

Delphi-Quellcode:

function ImportXMLThread(p: Pointer): Integer;
var
  ImPort            : TImport;
  Filename          : WideString;
begin

try
  Filename := PThreadParams(p)^.Filename;
  Import := TImport.Create(CurComputer, Filename);
  try
    if not Import.Import then
    begin
      SetCursor(LoadCursor(0, IDC_ARROW));
      case MessageBox(hApp, PChar(Format(rsImportError, [ExtractFilepath(ParamStr(0)) + LOGFILE])), PChar(APPNAME),
        MB_ICONWARNING or MB_YESNO) of
        IDYES: ShellExecute(hApp, 'open', PChar(ExtractFilepath(ParamStr(0)) + LOGFILE), nil, nil, SW_NORMAL)
      end;
    end;
  finally
    Import.Free;
  end;
except
//ggf. eine gewünschte Fehlerausgabe
end;

Result := 0;
end;

, und schon läuft auch das reibungslos.

[Aviator]

Du könntest ein Pull/Merge-Request auf GitHub erstellen damit Sebastian das einpflegen kann.

[Luckie]

Die CompilerSwitches.inc ist da drin, weil ich den Kommandozeilencompiler für die Batch nutze. Aber deines Debugging-Problems war ich jetzt auch etwas ratlos.

[Delphi-Laie]

Zitat von Aviator:

Du könntest ein Pull/Merge-Request auf GitHub erstellen damit Sebastian das einpflegen kann.

Warum einfach, wenn es auch ganz "hochoffiziell" möglich ist?

In meinen Augen gehört das eher zur Rubrik "issues". Ist jetzt jedenfalls dort als solcher auf höchst "intermediate English" eingetragen.

Danke für den Hinweis!

[jaenicke]

Zitat von Delphi-Laie:

Der Fehler passiert in der Funktion "ImportXMLThread" und erstaunt mich insofern, als daß dort doch mit "try..finally" ihm entgegengewirkt wird.

Oh, böse.
Die Methode Import liefern zwar einen Boolean zurück, schmeißt aber bei Misserfolg eine Exception.
Da das eine Threadmethode ist, landet die dann direkt in den aufrufenden Windows-Routinen.

Bei der Konstellation macht es gar keinen Sinn eine Exception zu werfen. Dazu kommt, dass Exception.Create in Unit Exceptions inherited nicht aufruft und somit die Message der Exception noch dazu leer ist.

try..finally sorgt ja nur dafür, dass Import.Free noch ausgeführt wird, behandelt aber den Fehler nicht.

Und CoDOMDocument40.Create ist auch etwas veraltet, das gibt es auch neueren Systemen vermutlich gar nicht mehr.

Ich schaue mal sobald ich dazu komme. Sollte schnell gehen.

[Luckie]

Zitat von jaenicke:

Zitat von Delphi-Laie:

Der Fehler passiert in der Funktion "ImportXMLThread" und erstaunt mich insofern, als daß dort doch mit "try..finally" ihm entgegengewirkt wird.

Oh, böse.

Ich war jung und brauchte den Code.

[jaenicke]

Zitat von Luckie:

Ich war jung und brauchte den Code.

Och, das passiert öfter als du vielleicht denkst.
Und solange man dann in diesem Fall nicht eine solche Fehleingabe macht, merkt man es ja auch nicht.

[Delphi-Laie]

Zitat von jaenicke:

Bei der Konstellation macht es gar keinen Sinn eine Exception zu werfen. Dazu kommt, dass Exception.Create in Unit Exceptions inherited nicht aufruft und somit die Message der Exception noch dazu leer ist.

Naja, ich glaubte bisher eigentlich, daß "try" einen solchen fehlerbedingten Programmabsturz zuverlässig bzw. immer verhindert.

Daß "except" im Fehlerfalle, und zwar unmittelbar danach, aktiv wird, ist klar.

Demnach hatte ich bisher bei "try...finally" eine solche Funktionalität im Hinterkopf, daß Fehler abgefangen, aber im Fehlerfalle (wird der Rest im try nach dem Fehler noch ausgeführt?) keine weitere Aktion erfolgt, danach aber in jedem Falle der Code im finally-Teil ausgeführt wird.