Rätselhafte Exception unter Windows 8

[idefix2]

Delphi-Quellcode:

procedure TFitnessMainForm.FormCreate(Sender: TObject);

begin
left:=0; top:=0;
showmessage ('Start');
// Position lesen
try left:=inifile.ReadInteger('Position','Links',left);
    width:=inifile.ReadInteger('Position','Breite',width);
    height:= inifile.ReadInteger('Position','Höhe',height);
    top:=inifile.ReadInteger('Position','Oben',top);
  except showmessage('exception 1');
  end;
showmessage('inifile gelesen');

Obiger Code produziert auf einem Rechner unter Windows 8 ein völlig rätselhaftes Verhalten. Nacheinander erscheinen, in der angegebenen Reihenfolge, die angehängten Messageboxen.
Obwohl zwischen dem ersten und dem zweiten Showmessage alles in einem try-except-block ist, wird zweimal diese Nachricht mit einer "Zugriffsverletzung" angezeigt, das

Delphi-Quellcode:

Showmessage('Exception2')

wird aber nicht ausgeführt.
Die inifile.readinteger funktionieren offenbar auch alle richtig, denn das Formular wird nicht am linken oberen Rand geöffnet, sondern dort, wo es sein soll.

Auf meinem Rechner mit Win7 wird keine derartige Fehlermeldung angezeigt, das ist nur am Kunden-PC der Fall.
Und nach dem Programmstart funktioniert alles normal, aber ich habe keine Ahnung, was die zwei Zugriffsverletzungsmeldungen sollen und wie ich die wegbekommen könnte.

[mkinzler]

Und was ist dabei rätselhaft? Du fängst den Fehler ja nicht ab.

Delphi-Quellcode:

 except
  on Exception do showmessage('exception 1');

[himitsu]

Ohne Einschränkungen werden alle Exceptions abgefangen.
Wobei immer alles abgefangen, aber nicht unbedingt behandelt wird.

[Dalai]

Wo wird das Objekt inifile erzeugt? Übrigens ist im Code kein

Delphi-Quellcode:

Showmessage('Exception2')

, also kann es kaum ausgeführt werden ;).

MfG Dalai

[hathor]

Es wird KEIN iniFile gelesen: entweder es ist nicht vorhanden oder es wird nicht gefunden.

Mit SCHLECHTEM Code kann man sich selbst in die Irre führen!

[BadenPower]

Zitat:

Zitat von hathor (Beitrag 1305560)

Es wird KEIN iniFile gelesen: entweder es ist nicht vorhanden oder es wird nicht gefunden.

Mit SCHLECHTEM Code kann man sich selbst in die Irre führen!

Das Code-Fragment im Eingangspost muss ein Pseudo-Code sein.
Den Beisweis liefert der Code in Verbindung mit den Bildern.

Wenn man schon nicht die originale Routine liefert, dann doch ein Pseudocode in dem ALLE relevanten Aufrufe stehen.

Die gepostete Routine wirft in allen Windowsversionen und nicht nur in Windows8 die Exception, da keine Instanz von TIniFile erstellt wurde.

Ich gehe davon aus, dass da noch weitere Anweisungen vor oder nach dem Try-Except-Block stehen, welche die Fehlermeldung auslösen.

[idefix2]

Zitat:

Zitat von mkinzler (Beitrag 1305550)

Und was ist dabei rätselhaft?

1. Wie himitsu schon geschrieben hat, müsste JEDE Exception dazu führen, dass der Except-Block ausgeführt wird
2. werden die Befehle im Try-Block alle ordnungsgemäss abgearbeitet, sonst würden die Eigenschaften Left und Top nicht gesetzt und die Form würde wegen der Zuweisungen ganz am Anfang (left:=0; top:=0) am oberen linken Rand geöffnet. Das ist nicht der Fall, die Position der Form stimmt, wenn sie angezeigt wird. Die Zuweisung an left ist die erste, die Zuweisung an top die letzte Anweisung des Try-Blocks.
Aber wenn eine Exception auftritt, dürften doch die Befehle nach der Exception nicht mehr ausgeführt werden.
3. funktioniert der gleiche Code auf meinem Win7 PC ohne irgendwelche Macken. Und ich erkenne im Code auch nichts, was irgenwie im Entferntesten ungewöhnich sein könnte

Mittlerweile fehlt mir jede Idee, wo ich weitersuchen könnte. Wenn der Fehler bei mir auftreten würde, könnte ich versuchen (mit wenig Hoffnung auf Erfolg), im Assembler-Fenster des Debuggers zu verfolgen, was passiert. Aber auf dem Kundenrechner ist ja nicht einmal ein Delphi installiert.

@Hathor
Wenn kein INi-File gelesen würde, dann hatte die Form beim Öffnen left=0 und top=0. Nachdem das nicht der Fall ist, wird das Ini-File gelesen.

Ich habe das Ganze weiter zerlegt, die Fehler passieren beim Zuweisen auf die Eigenschaften heigth und width:

Delphi-Quellcode:

try left:=inifile.ReadInteger('Position','Links',left);
    Showmessage ('Links gelesen');
    w:=inifile.ReadInteger('Position','Breite',width);
    Showmessage ('w gelesen');
    width:=w;
    Showmessage ('width zugewiesen');
    h:= inifile.ReadInteger('Position','Höhe',height);
    Showmessage ('h gelesen');
    height:=h;
    Showmessage ('height zugewiesen');
    top:=inifile.ReadInteger('Position','Oben',top);
    Showmessage ('oben gelesen');

Die Exception-meldungen werden angezeigt bei den Zuweisungen width:=w und heigth:=h. Was ich schon nicht verstehe.
Aber völlig unbegreiflich ist mir, dass er nach jeder solchen gemeldeten Exception normal weitermacht, ja sogar die Zuweisungen selbst richtig durchführt (Die Formulargrössen stimmen, die Höhe und Breite wird trotz der Exception-meldung richtig gesetzt.

[Der schöne Günther]

Das muss etwas anderes sein. Irgendeine abenteuerliche Komponente die auf deinem Formular liegt und der die Größenänderung ihres Parents (das Formular) nicht schmeckt. Ich würde wetten, mit einem Minimalbeispiel *1 tritt das nicht auf?


*1) Also einfach nur ein Formular das aus deiner Ini-Datei liest und dementsprechend sein

Delphi-Quellcode:

Width

und

Delphi-Quellcode:

Height

setzt?

[idefix2]

Hmmm...
Auf der Form liegen eigentlich nur ganz normale Delphi-Standardkomponenten, ein paar panels, ein Stringgrid, Edits etc.
Aber ich werde deinen Hinweis verfolgen und das Spiel mit einer leeren Form auf dem KundenPC durchspielen.

[baumina]

Die Fensterposition (Left, Top) und -größe (Width, Height) hängt auch von anderen TForm-Eigenschaften wie Position und Windowstate ab. Soviel ich weiß, sind die richtigen Werte der Festerposition- und -größe deswegen erst beim Zeichnen bekannt. Evtl. funkst du da im OnFormCreate zu früh dazwischen, deswegen würde ich das ins OnFormShow nach hinten verlegen.

EDIT : Ich Nehms zurück, denn ich machs auch im FormCreate.

EDIT : Allerdings hab ich mein Programm noch nie auf Win 8(.1) ausprobiert.

[bcvs]

Irgendeinen verdächtigen Code in OnResize?

[stahli]

Sieht fast so aus, als ob Self = nil wäre (wobei ich nicht wüsste, wie das passieren sollte)... - nee, Quatsch, passt nicht.

Aber kannst Du die Width-Zuweisung mit F7 debugen? Vielleicht wird dort irgendwas komisches getan? Dazu müsstest Du aber sicher irgendo eine Windows-Nachricht explizit abfangen und falsch behandelt haben.(?)
Fehler in OnResize ginge in die Richtung, aber OnResize wird ja nicht sofort dort aufgerufen sondern erst später von Windows gefeuert.

[idefix2]

Zitat:

Zitat von bcvs (Beitrag 1305570)

Irgendeinen verdächtigen Code in OnResize?

(Noch) kein OnResize

Zitat:

Zitat von stahli (Beitrag 1305573)

Sieht fast so aus, als ob Self = nil wäre (wobei ich nicht wüsste, wie das passieren sollte)...

Das Verrückte ist ja, dass die Exception angezeigt wird, aber alle Befehle werden richtig ausgeführt. Auch die Formulargrösse wird trotz der Exception-meldung beim Zuweisen richtig gesetzt.

[idefix2]

Zitat:

Zitat von stahli (Beitrag 1305573)

Aber kannst Du die Width-Zuweisung mit F7 debugen? Vielleicht wird dort irgendwas komisches getan? Dazu müsstest Du aber sicher irgendo eine Windows-Nachricht explizit abfangen und falsch behandelt haben.(?)

Eines der Probleme ist ja, dass ich das Problem auf dem Kundenrechner habe, bei mir benimmt sich das Programm völlig ordentlich. Dort habe ich keinen Debugger.

[stahli]

Dann würde mir nur noch ein Profiler wie EurekaLog oder http://www.delphipraxis.net/172214-d...-profiler.html einfallen. Vielleicht hilft so einer ja weiter.

[idefix2]

Der Kunde hat den Computer mit Windows 8.1 komplett neu aufgesetzt (bisher Windows 8.0), und das Programm startet jetzt völlig normal und ohne Fehlermeldung.
Leider wird sich jetzt wahrscheinlich nicht mehr herausfinden lassen, was wirklich schuld war.

[Der schöne Günther]

Zwei mal habe ich mir auch so etwas angetan, seitdem verlässt kein Programm mehr das aus das den Stacktrace seiner Exceptions nicht loggen kann. Tu dir den Gefallen und setze dich auch mal damit auseinander, dann braucht man in Zukunft nie mehr rätseln.

Warum das in der Delphi-RTL bis heute nicht von Haus aus schon drinsteckt wird sich mir nie erschließen.

[p80286]

Zitat:

Zitat von idefix2 (Beitrag 1305686)

Der Kunde hat den Computer mit Windows 8.1 komplett neu aufgesetzt (bisher Windows 8.0), und das Programm startet jetzt völlig normal und ohne Fehlermeldung.
Leider wird sich jetzt wahrscheinlich nicht mehr herausfinden lassen, was wirklich schuld war.

Meiner Meinung nach, greift da irgendetwas mit Schwung ins Klo. In ordentlichen Programmen passiert so etwas nicht. (Hatte selbst vor einiger Zeit den Fall, einem Pointer war keine Adresse (mehr) zugewiesen.) Wenn eine solche Exception einmal aufgetreten ist, dann ist da irgendetwas faul! Und es ist Zufall, wenn sie nicht mehr auftaucht, wenn am Source nichts geändert wurde.

Gruß
K-H

[idefix2]

Zitat:

Zitat von Der schöne Günther (Beitrag 1305695)

Zwei mal habe ich mir auch so etwas angetan, seitdem verlässt kein Programm mehr das aus das den Stacktrace seiner Exceptions nicht loggen kann. Tu dir den Gefallen und setze dich auch mal damit auseinander, dann braucht man in Zukunft nie mehr rätseln.

Hast du dafür ein fertiges Tool eingesetzt (wenn ja, welches?) , oder ist das Eigenbau?
Wobei ich in dem konkreten Fall sogar skeptisch bin, ob das etwas gebracht hätte, weil hier nicht einmal das normale Exception-Handling aktiviert worden ist und das Programm nach der Anzeige der Fehlermeldung sogar die Zuweisung, die die Fehlermeldung ausgelöst hat, fertig durchgeführt hat und dann ganz normal beim nächsten Befehl weitergemacht hat.

Zitat:

Zitat von p80286 (Beitrag 1305707)

Zitat:

Zitat von idefix2 (Beitrag 1305686)

Der Kunde hat den Computer mit Windows 8.1 komplett neu aufgesetzt (bisher Windows 8.0), und das Programm startet jetzt völlig normal und ohne Fehlermeldung.
Leider wird sich jetzt wahrscheinlich nicht mehr herausfinden lassen, was wirklich schuld war.

Meiner Meinung nach, greift da irgendetwas mit Schwung ins Klo. In ordentlichen Programmen passiert so etwas nicht.

Im Prinzip richtig, in dem Fall neige ich aber dazu, die Windows Installation des Kunden für das "nicht ordentliche" Programm zu halten.
Wenn ganz am Anfang eines Programms beim blossen Ändern der Formulargrösse des Hauptformulars im Formcreate eine derartige Meldung auftritt - da hatte das Programm noch gar keine Gelegenheit, irgend einen Mist zu bauen - die Formulargrösse aber trotzdem richtig angepasst wird, dann dürfte der Knoten irgendwo weiter unten im Betriebssystem sitzen.

[SMO]

Zur Intention des Codes: du möchtest bei Programmstart die Position und Größe des Fensters wiederherstellen, gespeichert beim letzten Programmende?
Dafür würde ich unter Windows eher SetWindowPlacement und GetWindowPlacement nehmen.
Ich weiß nicht, ob deine TFitnessMainForm maximiert werden kann oder nicht, aber wenn ja, dann ist es möglich, dass das Fenster bei Programmende maximiert ist und du so die maximierte Position und Größe speicherst und dann beim nächsten Programmstart diese "falschen" Werte dem nicht-maximierten Fenster zuweist. Mit Get/SetWindowPlacement kommst du direkt an die Koordinaten des Normalzustands (rcNormalPosition).

Ungefähr so:

Delphi-Quellcode:

procedure PositionSpeichern(F: TForm; Ini: TCustomIniFile);
var
  WP: TWindowPlacement;
begin
  WP.length := SizeOf(WP);
  if GetWindowPlacement(F.Handle, WP) then
  begin
    Ini.WriteInteger('Position', 'Links', WP.rcNormalPosition.Left);
    Ini.WriteInteger('Position', 'Rechts', WP.rcNormalPosition.Right);
    Ini.WriteInteger('Position', 'Oben', WP.rcNormalPosition.Top);
    Ini.WriteInteger('Position', 'Unten', WP.rcNormalPosition.Bottom);
    Ini.WriteBool('Position', 'Maximiert', F.WindowState = wsMaximized); // oder WP.showCmd = SW_SHOWMAXIMIZED
  end
  // else Fehlerbehandlung
end;

procedure PositionLaden(F: TForm; Ini: TCustomIniFile);
var
  WP: TWindowPlacement;
begin
  ZeroMemory(@WP, SizeOf(WP));
  WP.length := SizeOf(WP);
  WP.rcNormalPosition.Left := Ini.ReadInteger('Position', 'Links', F.Left);
  WP.rcNormalPosition.Right := Ini.ReadInteger('Position', 'Rechts', F.Left + F.Width);
  WP.rcNormalPosition.Top := Ini.ReadInteger('Position', 'Oben', F.Top);
  WP.rcNormalPosition.Bottom := Ini.ReadInteger('Position', 'Unten', F.Top + F.Height);
  if not Ini.ReadBool('Position', 'Maximiert', F.WindowState = wsMaximized) then
    WP.showCmd := SW_SHOWMAXIMIZED
  else
    WP.showCmd := SW_SHOWNORMAL;
  SetWindowPlacement(F.Handle, WP);
end;

[idefix2]

Danke für den Hinweis, GetWindowPlacement und SetWindowPlacement kannte ich noch nicht.
Wenn der Rechner noch in einem Zustand wäre, wo das Problem auftritt, dann würde ich das ausprobieren. Bis jetzt hatte ich allerdings noch nie beim direkten Setzen der Form-Eigenschaften height und width Probleme, und dass sich Forms ihre Position und Grösse in einer ini-Datei oder, wenn es im Programm eine Benutzerverwaltung gibt, Benutzerabhängig in der Datenbank, merken, je nach Bedarf mit oder ohne Berücksichtigung der Eigenschaft maximized, mache ich eigentlich standardmässig bei allen meinen Programmen.

edit:
Welche Unit muss man einbinden, damit der Compiler TWindowplacement kennt? In der Hilfe zu Delphi 2009 finde ich zwar die Prozeduren GetWindowPlacement und SetWindowPlacement, aber für die Struktur Windowplacement sind nur die C-Headerfiles angegeben und TWindowplacement kennt die Hilfe überhaupt nicht.

[SMO]

Zitat:

Zitat von idefix2 (Beitrag 1305865)

Welche Unit muss man einbinden, damit der Compiler TWindowplacement kennt?

Die Unit (Winapi.)Windows. Die typischen Synonyme für TWindowPlacement sind tagWINDOWPLACEMENT und WINDOWPLACEMENT. Falls keines davon geht, wurde der Record wohl noch nicht in Delphi 2009 definiert.

Delphi-Quellcode:

  TWindowPlacement = record
    length: UINT;
    flags: UINT;
    showCmd: UINT;
    ptMinPosition: TPoint;
    ptMaxPosition: TPoint;
    rcNormalPosition: TRect;
  end;

[himitsu]

Aber wenn du die Funktionen schon gefunden hast, wer hat dich dann daran gehinder sie dir anzusehen und mal zu gucken wo die Typen für deren Parameter liegen?

[Sir Rufo]

Zitat:

Zitat von himitsu (Beitrag 1305890)

Aber wenn du die Funktionen schon gefunden hast, wer hat dich dann daran gehinder sie dir anzusehen und mal zu gucken wo die Typen für deren Parameter liegen?

Es ist halt einfacher und schneller eine Frage im Forum zu posten als in der IDE den Mauszeiger über den Typen zu halten und warten bis der ToolTip erscheint (den muss man ja auch noch lesen) ... :roll:

[idefix2]

@himitsu
Es ist wohl nicht der Sinn der Delphi IDE, dass man die in irgendwelchen Units schon vordefinierten Typen in seinem Programm selbst neu deklariert. Oder?

@Sir Rufo
Nachdem die IDE den Typ nicht kennt, erscheint auch kein Tooltip. Hab ich wohl deutlich lesbar geschrieben:

Zitat:

Zitat von idefix2 (Beitrag 1305865)

... aber für die Struktur Windowplacement sind nur die C-Headerfiles angegeben und TWindowplacement kennt die Hilfe überhaupt nicht.

Auf die Unit Windows hätte ich selbst auch kommen können, habe aber fälschlich geglaubt, dass ich in meiner Unit die unit Windows schon eingebunden habe und der Typ trotzdem nicht bekannt ist. Aber Windows war noch nicht in der Uses Liste.

[himitsu]

Doch, das kannst du machen, aber dann darfst du auch die API-Aufrufe neu implementieren, da deine Typen bestimmt nicht mit denen der vorhandenen Funktionen kompatibel sind. :roll:

Zitat:

Zitat von idefix2 (Beitrag 1305928)

Nachdem die IDE den Typ nicht kennt, erscheint auch kein Tooltip.

Du solltest ja auch nicht bei dir gucken, sondern bei der Deklaration der Funktionen.

PS: Strg+Shift+F und als Suchverzeichnis

Delphi-Quellcode:

$(BDS)

in

Delphi-Quellcode:

*.pas;*.dfm;*.inc;*.dpr

suchen.