TLabel - für mich unerklärliche Exception

[TurboMartin]

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.

[Ralf Kaiser]

Zitat von TurboMartin:

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

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)

[mani64]

Zitat von TurboMartin:

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.

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 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...

[TurboMartin]

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