Exception ''access violation ' beim beenden des Programms

[himitsu]

Delphi löst ein WITH gerne so auf:

Delphi-Quellcode:

function StartfrUnterschrift:TModalResult;
var
  AutomatischGenerierteVariable: TfrUnterschrift;
begin
  //with frUnterschrift do
  AutomatischGenerierteVariable := frUnterschrift;
  begin
    frUnterschrift := TfrUnterschrift.create(Application);
    try
      result := AutomatischGenerierteVariable.ShowModal;
    finally
      AutomatischGenerierteVariable.release;
      frUnterschrift:=nil;
    end;
  end;
end;

Und jetzt mag gern jemand raten, was da nun passiert.

Und wozu gibt es da überhaupt eine globale Variable "frUnterschrift", wo die ja scheinbar nicht außerhalb benutzt wird, oder etwa doch?

Delphi-Quellcode:

function StartfrUnterschrift: TModalResult;
begin
  with TfrUnterschrift.Create(Application) do
  begin
    try
      Result := ShowModal;
    finally
      Free;
    end;
  end;
end;

Beim Release wird das Free nicht sofort ausgeführt, sondern verzögert "irgendwann" später mal,
was auch gerne Probleme erzeugt und vorallem beim Focus ist uns das schon schmerzhaft auf die Füße gefallen.

Und das "Start" im Namen stimmt auch nicht wirklich, denn das Fenster wird erzeugt (gestartet), verarbeitet (ShowModal) und wieder beendet (Release/Free).

[Kostas]

Die Variable "frUnterschrift" ist die Formvariable die die Form repräsentiert, wird von Delphi erstellt.

Ihr habt recht. Das With ist völlig überflüssig gewesen. Ich verwende dennoch das With wie angezeigt
da ich meist vor dem ShowModal irgend welche Initialisierungen mache und nach dem ShowModal übergebe ich
die Rückgabewerte. Das With verwende ich damit ich die Formvariable nicht jedes mal angeben muss.
Bis Dato hatte ich damit auch nie Probleme. Diesem Methodenrumpf habe ich mir als Vorlage abgelegt und
verwende sie tausendfach. In diesem Fall wo nichts initialisiert wird und nicht zurückgegeben wird ist es
völlig unnötig.

Das Create im With mache ich bewusst nicht mehr. Damit hatte ich schon massive Probleme. Wenn ich z.B. über einen
qualifizierten Bezeichern arbeiten muss habe ich keinen Zugriff auf die Formvariable da die Form im With erzeugt wird.
Es gab noch mehr Probleme, ich kann mich aktuell nicht an einen Fall erinnern.

Delphi-Quellcode:

function StartfrUnterschrift: TModalResult;
begin
   with TfrUnterschrift.Create(Application) do
   begin
     try
       Result := ShowModal;
     finally
       Free;
     end;
   end;
end;

Gruß Kostas

[himitsu]

Zitat von Kostas:

Die Variable "frUnterschrift" ist die Formvariable die die Form repräsentiert, wird von Delphi erstellt.

Sagen wir es mal so: Ich würde diese Variablen am Liebsten abschaffen, aber wenn man alle Formulare automatisch erstellen läßt, geht es ohne nicht so gut.
Vorallem bei manuell erstellten Formularen sollte man am Besten die Finger davon lassen und diese Variable einfach löschen.

Bis Dato hatte ich damit auch nie Probleme. Das dachte Viele und dann knallte es plötzlich.

PS: Records können Methoden und Property enhalten.
Jetzt hat "endlich" TPoint und TRect ganz nette Funktionen direkt eingebaut und nicht mehr wild sonstwo als Funktionen rumliegen.

Delphi-Quellcode:

var
  R: TRect;


with R do begin
  ...
  {eigentlich nicht R.}Height := {R.}Bottom - {R.}Top;
  {eigentlich nicht R.}Offset := {R.}Top;
end;

Könnte z.B. das Height der Form sein, oder z.B. von einem TBitmap, welchers drumrum ebenfalls via WITH rumgammelt.
Oder eine Variable "Offset".

Tja, und nun hat man seinen Spaß.

Das OFFSET knallt, weil mit TRect.Offset nun eine Funktion existiert.
Und es gibt jetzt ein solches HEIGHT-Property, somit wird es nun zu R.Height:= und ist nicht mehr das andere Height.

[Kostas]

Ja, in C# ist das alles deutlich besser gelöst.
Eigentlich wird es Zeit dass Delphi in Ihrer Sprache wächst.

[Edit] C# hat leider mittlerweile solche Dimensionen erreicht dass es hoffnungslos überfrachtet ist meiner Meinung nach.

[Edit] Ich habe soeben in der Main Form eingefügt:

Delphi-Quellcode:

initialization

finalization
  MessageDlg('Test', mtWarning, [mbOK], 0);

Die Exception wird erst nach dem MessageDlg gefeuert. Somit ist klar warum madExcept und EurekaLog nicht haben reagieren können.
Die Exception wird somit außerhalb vom Programm gefeuert. Jetzt bleibt nur der Weg zum Hersteller des SignPads.

Gruß Kostas

[Stevie]

Zitat von Kostas:

Ja, in C# ist das alles deutlich besser gelöst.
Eigentlich wird es Zeit dass Delphi in Ihrer Sprache wächst.

Wir sollten mal bald ne Petition starten - eventuell tut sich ja dann mal was.

Zitat von Kostas:

C# hat leider mittlerweile solche Dimensionen erreicht dass es hoffnungslos überfrachtet ist meiner Meinung nach.

Och C# an sich ist doch recht fein - wenn man ne englische Tastatur für die Klammern hat

[Kostas]

Hallo Zusammen,

ich hatte heute Zeit und hab die Ursache lokalisieren können.
Für die Anwendung verwende ich ein SignPad und eine Unterschrift zu digitalisieren.
Auch wird die Komponente TJvMultiStringHolder verwendet, hat aber nicht mit dem SignPad zu tun.

Wenn im Projekt die Komponente TJvMultiStringHolder vorkommt und das SignPad eine Unterschrift digitalisiert
und die Anwendung wird beendet, dann kommt die Exception. Entferne ich die Komponente, so funktioniert alles einwandfrei.
Oder ich digitalisiere nicht. Das habe ich in einem neuen Testprojekt feststellen können.

Übrigens, das ist das zweite SignPad. Zuerst hatte ich eines von Wacom und genau den gleiche Fehler gehabt. Da war ich der
Meinung, natürlich liegt es an Wacom. Die haben den Treiber ober API nicht sauber programmiert. Dann habe ich Wacom entsorgt
und bei StepOver eingekauft. Die Überraschung war groß als ich die Exception schon wieder bekommen habe.


Gruß Kostas.

P.S. Kennt jemand eine alternative Komponente zu TJvMultiStringHolder? Es geht darum das in der Exe mehrere String gebunkert werden können.
Ich benutze das als Updatescripts um eine FB-DB in Abhängigkeit von der Exe-Version die DB-Struktur hoch zu ziehen.
[Edit] ich habe eine Ersatzkomponente gefunden für TJvMultiStringHolder http://www.torry.net/authorsmore.php?id=4529
Damit gibt es keine Probleme.

[Union]

Ja, die Alternative heißt resourcestring bzw. rc-file und brcc.

[himitsu]

Zitat von Kostas:

P.S. Kennt jemand eine alternative Komponente zu TJvMultiStringHolder? Es geht darum das in der Exe mehrere String gebunkert werden können.

TStringList?
Wenn es wirklich eine TStringList ist (kein anderer TStringsNachfahre), dann kann man dort in jede Zeile jedes SL[i] bzw. SL.Strings[i] mehrere "Zeilen" reinmachen. (man darf nur niemals über SL.Text, SL.SaveFile usw. gehen, da dort die Zeilenumbrüche aufgelöst werden)
Via TStringList.Values kann man auch die Einträge namentlich verwalten.

Oder TDictionary<string,string> bzw. TObjectDictionary<string,TStringList> .


Diese Komponenten muß man zwar selber verwalten, aber was soll's.

PS: Deine "Ersatzkomponente" ist sowas ähnliches wie das TObjectDictionary, also mehrere TStringListen in einer Komponente, nur daß diese Dictionaries wie eine Hash-Liste arbeiten und somit einen schnelleren Zugriff bieten.