TLabel - für mich unerklärliche Exception

[mani64]

Hallo,

wer kann mir folgendes erklären:
Ich habe in einer MDI-Anwendung ein Formular, ein "About"-Fenster, das beim Start kreiert wird und dann per Menü-Button aufgerufen werden kann (siehe bei Delphi Datei - Neu - Projekte - MDI-Anwendung!).
Auf dem Formular sind 3 TLabel und ein Image.
Bei dem einen Label ist die Textgröße Font.Size auf 8 eingestellt, die Werte von Font.Height und Height sind -11 und 13.
So funktioniert die Sache wunderbar.

Ändere ich jetzt Font.Size ab, dann passen sich im Objektinspektor auch Font.Height und Height an, z.B. Font.Size=16, Font.Height=-21 und Height=24. Aber nun erzeugt das Programm beim Verlassen eine Exception EAccessViolation in Modul Projekt1.exe... Zugriffsverletzung ... Schreiben von Adresse ....
Rufe ich jedoch bevor ich das Programm schließe das About-Formular auf, kommt die Meldung nicht.
Die Meldung kommt auch nur, wenn ich zuvor in ein Kindfenster eine bereits vorhandene Datei lade.
Stelle ich für Label die ursprünglichen Werte ein, dann wird das Programm aber auch normal beendet, auch wenn ich das About-Formular nicht erscheinen lasse und eine Datei geöffnet hatte.
Die Meldung erscheint auch nicht (bei veränderten Werten des Labels), wenn ich zuerst das Kind-Fenster schließe und danach dann das Programm beende.

Welche Erklärung gibt es für dieses Phänomen??

Ich habe jetzt gerade noch einmal die von Delphi zur Verfügung gestellte Grundform von MDI-Applikation getestet. Dort hat das Verändern von Font.Size keine Exception zur Folge. Ist doch aber komisch, dass es in meiner Anwendung mit Font.Size 8 keine Exception gibt, mit jeder anderen Größe aber schon - jedoch wenn ich das Formular einmal aufgerufen habe, dann wieder keine.

[jbg]

Zitat:

Zitat von mani64

Welche Erklärung gibt es für dieses Phänomen??

Speicherüberschreibung. Irgendwo überschreibt oder verwendest du Speicher der nicht dir gehört. Und durch das Ändern der Font.Size ändert sich die Speicherbelegung so, dass es zufälligerweise nicht zu einer Schutzverletzung kommt.

[mani64]

Danke für den Hinweis.

So etwa hatte ich auch vermutet, aber solch ein Fehler ist manchmal schwer zu finden. Anscheinend lässt sich bei TRichedit MaxLength nicht direkt setzen, sondern nur mit einem Aufruf SendMessage(handle,EM_EXLIMITTEXT, 0, value) - ich hatte den Wert einfach mit Richedit.Maxlength:=value zugewiesen. Jedenfalls geht es nach dieser Korrektur ohne Fehlermeldung.
Seltsamerweise muss ich vor dem Einlesen der Datei die Größe von Maxlength ändern, ganz entgegen dessen, was in der Delphi-Hilfe steht, nämlich dass bei dem Vorgabewert 0 die Textgröße nur durch das Betriebssystem begrenzt sei. Jedenfalls liest das Betriebssystem einen RTF-Text nur bis zu einer bestimmten Größe ein und bricht ab, falls der Text länger ist, und liest ihn dann als normalen Text ein. Wenn ich dagegen Maxlength auf den Wert setze, den Delphi (blöderweise) erst nach dem Einlesen der Datei selbst setzt ($7FFFFFF0), dann wird die Datei richtig eingelesen, auch wenn sie etwas größer ist.

Edit:
Nein, das war es wohl noch nicht. Jedenfalls klappt es im Augenblick wieder nicht mehr ohne Fehlermeldung. :cry:
Keine Ahnung, wo ich da in einen flaschen Speicherbereich schreibe...


Edit2:
Mann, wie einfach doch manchmal die Dinge sind! Aus irgendeinem Grund habe ich versehentlich auf dem 1. Formular eine Popup-Neuü-Komponente plaziert, die da gar nicht hin gehört. Komponente gelöscht und schon funktioniert es wieder :-D

[sx2008]

Zitat:

Zitat von mani64

Komponente gelöscht und schon funktioniert es wieder :-D

Damit hast du deinen Fehler aber noch nicht gefunden sondern nur das Speicherlayout geändert.
Es ist mehr oder weniger Zufall, dass jetzt die Zugriffsverletzung ausbleibt.

[mani64]

Gibt es irgendwie einen Weg, diesen Fehler aufzuspüren?

[Poelser]

Zitat:

Zitat von mani64

Gibt es irgendwie einen Weg, diesen Fehler aufzuspüren?

Projekt (komplett) erzeugen mit allen Einstellungen für Laufzeitfehler:

- Bereichsüberprüfung
- I/O-Prüfung
- Überlaufprüfung

Vielleicht hast du dann Glück, dass du dann schon eine Exception á la "Fehler bei der Bereichsprüfung" bekommst. Man sollte zur Entwicklungszeit immer mit diesen Schaltern compilieren.

CU, der Poelser

[Luckie]

Man könnte noch die madexcept Komponenten von Madshi nutzen. Oder sich einfach mal den Code im CPU-Fenster angucken und zurückverfolgen.

[mani64]

Ich weiss mir keinen Rat mehr :wall:

Bitte schaut euch mal mein Projekt an, vielleicht könnt ihr einen Fehler entdecken. Es ist noch nicht ganz fertig. Das Formular von Unit3 ist noch nicht vollständig integriert. Es wird ein Dialogformular, mit dem Änderungen in der Unit converter durchgeführt werden sollen. Wenn ich Form3 nicht automatisch erstellen lasse, wird das Programm ohne Exception beendet. Vielleicht liegt ja da irgendwo ein Fehler. Keine Ahnung, ob ich Unit3 erst fertig programmieren muss; ich denke, es sollte auch beim jetzigen Stand funktionieren.

Bitte einmal testen: Programm starten, die Datei log06689 2.txt laden und danach das Programm beenden (entweder im MainForm auf das x rechts oben klicken oder mit Datei-beenden).

Bin für jeden Rat dankbar

[Ralf Kaiser]

Hallo,

ich habe das PRogramm noch nicht selbst compilliert aber wenn ich es starte, die Datei lade und dann beende dann stürtzt nichts ab! - Keine Exception, keine Fehlermeldung.

Ist das jetzt gut? (getestet auf einem Vista Ult.)

Ciao,
Ralf

[mani64]

Toll für dich!

Bei mir stürzt es leider ab; ich arbeite mit Windows XP. Ich lade mal noch die EXE-Datei hoch.

Aber vielen Dank für dein Bemühen.


Ich habe versucht, die Stelle zu finden, bei der die Exception geschieht. Anscheinend passiert es bei der Freigabe des Menüs. Ich habe aber keine Ahnung warum.

[TurboMartin]

Zitat:

Zitat von Alfi001

Hallo,

ich habe das PRogramm noch nicht selbst compilliert aber wenn ich es starte, die Datei lade und dann beende dann stürtzt nichts ab! - Keine Exception, keine Fehlermeldung.

Ist das jetzt gut? (getestet auf einem Vista Ult.)

Ciao,
Ralf

Schonmal in den Taskmanager geschaut? Da hängt das Programm bei mir mit jeweils 45% CPU-Last dinnnen. :stupid:

[Ralf Kaiser]

Zitat:

Zitat von TurboMartin

Schonmal in den Taskmanager geschaut? Da hängt das Programm bei mir mit jeweils 45% CPU-Last dinnnen. :stupid:

Danke für den Hinweis! Ich hatte mich schon gewundert, warum mein Rechner seit ein paar Stunden teilweise recht träge ist (ich hatte es mehrfach gestartet)

:wall:

[mani64]

Zitat:

Zitat von TurboMartin

Zitat:

Zitat von Alfi001

Hallo,

ich habe das PRogramm noch nicht selbst compilliert aber wenn ich es starte, die Datei lade und dann beende dann stürtzt nichts ab! - Keine Exception, keine Fehlermeldung.

Ist das jetzt gut? (getestet auf einem Vista Ult.)

Ciao,
Ralf

Schonmal in den Taskmanager geschaut? Da hängt das Programm bei mir mit jeweils 45% CPU-Last dinnnen. :stupid:

Das kann ich nicht bestätigen. Ich hab es mehrmals gestartet und es lastet bei mir die CPU so gut wie überhaupt nicht aus (hächstens 11%, wenn ich nach einem Wort suchen lasse), weder in der Entwicklungsumgebung noch als EXE-Datei.

Außerdem: Wieso sollte das so sein, bzw. wie ließe sich diese hohe Auslastung vermeiden? Kann es eventuell mit dem anderen Betriebssystem (Vista) zusammenhängen?

[Ralf Kaiser]

Hallo,

ich habe das Programm gerade mal mit D2007 unter Vista compilliert. Wenn ich es starte, die Datei lade und dann beende wird es ohne Fehlermeldung beendet,

Der Unterschied zu der von dir compillierten Exe: Deine Version blieb nach dem beenden im Taskmanager hängen, die "frisch" compillierte Version tut das nicht.

Gibt es einen Grund, warum du die Unit "ComCtrls.pas" direkt ins Projekt eingebunden hattest?

Ciao,
Ralf

[mani64]

Zitat:

Zitat von Alfi001

Gibt es einen Grund, warum du die Unit "ComCtrls.pas" direkt ins Projekt eingebunden hattest?

Ciao,
Ralf

Ja, ich brauchte die Datei zum Debuggen. Ich musste ja erst herausfinden, wie das mit dem Richedit so funktioniert.

In ein paar Tagen bekomme ich Delphi 2009, bin gespannt, wie es dann ist. Momentan habe ich noch Delphi 5. Kann es daran liegen, dass das Programm unter XP mit einer Fehlermeldung endet? Es geschieht ja auch nicht immer, deshalb ist es für mich so ein Rätsel. Z.B. wenn ich die Datei lade und dann im Menü Ansicht - Datei neu laden wähle und danach beende, dann kommt bei mir keine Fehlermeldung. Wenn ich aber den Menüpunkt von Form1 aus direkt nach dem ersten Ladevorgang durch eine Programmzeile aufrufe mit Kind.Dateineuladen1Click(self), dann kommt die Fehlermeldung beim Beenden.

[Ralf Kaiser]

MIr ist da eben nochwas aufgefallen:

Du hast da auf dem Form2 einen Timer der immer aktiv ist. Versuch doch mal was passiert, wenn dieser Timer deaktiviert wird bevor das Fenster geschlossen wird. z.B in OnCloseQuery den Timer auf Enabled:=false setzen.

Im Eventhandler des Timers wird ja auf Komponenten des Formulars zugegriffen (wobei ich bisher dann nicht verstehe, warum es bei einem frischen D2007-Compillat dann nicht passiert...)

Nur so ne Idee...

[mani64]

Timer.Enabled auf false zu setzen verändert leider auch nichts. Ich unterbinde den größten Teil der Timer-Prozedur ja eh mit dem Status von update.

Ich bin nun mit Form3 einen kleinen Schritt weiter und habe die Form modal erzeugt, um mal zu sehen, wie es aussieht und was ich noch programmieren muss. Und nach dem Aufruf von Form3 war ein Beenden des Programms ebenfalls ohne Fehlermeldung möglich. Das muss doch herauszufinden sein, wieso einmal eine Exception kommt und beim nächsten Mal nicht.

[TurboMartin]

Das Problem entsteht durch dein Richedit, welches Du für kurze Zeit in FormCreate der Unit1 erstellst. Probier doch mal [oh]AppendConversionFormat[/oh].

[mani64]

O, danke für den Hinweis! Wenn ich die Zeile Richedit1.destroy weglasse, dann erfolgt keine Exception. Das Richedit ist ja nicht sichtbar, also stört es auch nicht, wenn es am Leben bleibt.
Aber: wieso führt dieses Richedit zu einer Exception? Es muss doch möglich sein, dieses Ding zur Laufzeit zu erschaffen und wieder zu zerstören. Hey, mit richedit.free statt .destroy scheint es zu klappen. - Jetzt bin ich aber ganz baff! Auf einmal geht es auch mit .detroy völlig ohne Exception. Ist mir ein Rätsel, warum es auf einmal klappt. Vielen Dank!


AppendConversionFormat gibt es bei mir (Delphi 5.0) nicht, nur RegisterConversionFormat. Ich möchte meinen Converter eben einmal registrieren beim Start des Hauptformulars und nicht mit jedem Kindfenster, denn dann wird er ja x-mal registriert. Leider gibt es keinen direkten Zugriff auf die Konverter der Unit ComCtrls. Deswegen muss ich z.B. auch im Kindfenster das Richedit löschen und ein neues erschaffen, wenn die Dateiendung z.B. von txt auf rtf geändert wird. Man kann weder auf die Liste der Konverter noch auf den geladenen Konverter eines Richedit direkt zugreifen. Der wird fürs Richedit einmal geladen und danach auch weiter verwendet, selbst wenn die Dateiendung und damit das Format beim Speichern geändert wurde.


Edit:
Nun passiert folgendes: Wenn ich in Unit1 das Richedit mit .free oder .destroy ins Jenseits schicke, eine .txt-Datei lade und die unter .rtf speichere (d.h. das Richedit im Kindfenster lösche und neu erstelle), und danach beende, kommt die Exception wieder.
Wenn ich aber das Richedit in Unit1 bestehen lasse, kommt nach dem Speichern keine Exception - Computer sind schon seltsame Wesen.

Noch ein Edit:
Ich habe den Converter etwas verändert, um Form3 ins Programm integrieren zu können und nun kommt die Exception immer, wenn ich speichere und danach das Programm beende. Also das Richedit1 der Unit1 kann es nicht (allein) sein. Es muss noch irgendwo was anderes stecken... :wall:

[TurboMartin]

Hallo, ich meinte das vor dem destroy, ohne das läuft alles glatt.

[mani64]

Ich hab es jetzt anders gelöst, so dass ich auf dieses Richedit in Unit1 verzichten kann, und zwar mit einem flag "first", so dass nur bei dem ersten Aufruf eines Kindfensters der Konverter registriert wird.
Aber seltsamerweise funktionierte es plötzlich auch schon vorher ohne Exception! Auf einmal. Hab keine Erklärung dafür.
Habe mal in dem About-Formular wieder die Schriftgröße geändert, und es geht! Und dann hab ich sie auf den alten Wert zurück gesetzt, und es geht immer noch ohne Fehlermelung. Na ja, jetzt lasse ich es so und mache mein Formular der Unit3 fertig.

Vielen Dank an alle, die geholfen haben.