Zugriffsverletzung bei Application.HandleMessage

[Caps]

Hallo DP,

ich bin ein wenig ratlos, weil ich eine Zugriffsverletzung in folgendem Codeabschnitt bekomme:

Delphi-Quellcode:

FormDATKalkUebernahme.Show;
Repeat
  Application.HandleMessage;
until FormDATKalkUebernahme.ModalResult <> mrNone;

Die Exception meint: "Zugriffsverletzung bei Adresse 00000017. Lesen von Adresse 00000017" .
Ich gebe zu, das sind nicht viele Informationen und sehr wenig Code, aber ich brauche eigentlich nur einen hilfreichen Hinweis dazu, wie ich das Ding debuggen kann :gruebel:.
Ich kann zwar im Schrittmodus über die Schleife laufen, aber alles was ich bekomme ist diese Meldung. Leider lassen sich die mitgelieferten Delphi-Units nicht debuggen (oder doch?), daher stehe ich auf dem Schlauch, wie ich die Ursache dieser Exception finden könnte.

Noch ein paar Informationen dazu:
Die Form FormDATKalkUebernahme existiert zum Zeitpunkt der Schleife (sonst ginge das Show ja bereits schief) und hat ein paar Controls drauf.
In dem Moment, in dem ein Tastaturereignis oder ein Mausereignis auf einer Control "passiert", tritt der Fehler auf, d.h. im Schrittmodus kann ich auf ein Control klicken - zunächst passiert nix - dann drücke ich ein paar mal F8 in der IDE, solange bis (vermutlich) die Mausmessage an der Reihe ist, und dann knallt's.
Ein Klick auf das Panel, auf dem die Controls liegen bringt keine Exception.

Also zusammenfassend: Wie kann ich Application.HandleMessage debuggen?

Jemand ne Idee?
Zu hülf! :freak:

lg Caps

[CCRDude]

Delphi-Units kannst Du schon debuggen, siehe Projekteinstellungen -> Delphi Compiler -> Compiling -> Debugging -> Use debug .dcus.

Aber...

• Wolltest Du evtl. ProcessMessages statt HandleMessage aufrufen?
• Der Debugger bringt nicht viel, da er nicht zu den Empfängern von Nachrichten springt.
• Wenn beide Formulare parallel bedienbar sein sollen (sonst wäre ShowModal statt der Schleife ja einfacher), warum dann nicht per Event mitteilen, wenn das Übernahme-Fenster geschlossen wird?

Oder anders ausgedrückt: Konzept prüfen und überarbeiten dürfte deutlich weniger zeitinsensiv sein als alle möglichen Empfänger von Nachrichten zu prüfen.

[generic]

Warum nutzt du nicht

Delphi-Quellcode:

form.showmodal

?
Dann brauchst du die Schleife nicht.

[Caps]

Hi, danke für die schnellen Antworten!

@generic:
ShowModal kann ich leider nicht benutzen, weil unsere Formverwaltung auf die gezeigte Weise funktioniert, sorry, aber danke für den Vorschlag. Weitere Ideen? ;-)

@CCRDude:
1) Ich werde das mal probieren, die Delphi-Units zu debuggen, danke.

2) Konzept überarbeiten ist leider nicht möglich, weil unsere komplette Anwendung so funktioniert.
Ich werde mal ProcessMessages verwenden, aber da alle unsere Forms auf diese Weise mit HandleMessage funktionieren, denke ich, dass da nicht der Fehler liegen kann.

Ich würde halt gern wissen, welche Nachricht das ist, die da "scheitert".

Die Forms sollen nicht beide gleichzeitig bedienbar sein, aber sie werden auf eine Weise auf das Hauptformular gezeichnet, die diese komische Art der Anzeige erfordert, sorry.


Danke für die Antworten, aber ich glaube, das behebt das Problem nicht... :|
Sorry

[Caps]

Der Fehler tritt innerhalb von TApplication.ProcessMessage in der Zeile "if PeekMessage(..." auf.
Die wird leider aus einer Windows-DLL geholt, hier ist also Schluss... :kotz:

Mal sehen... das ist ja ******, wat mach ick denn da jetze... ist es möglich die betreffende Message irgendwie zu übersetzen/ verständlich zu machen? Den Message-Empfänger herauszufinden, o.ä.?

lg Caps

[Uwe Raabe]

Zitat:

Zitat von Caps (Beitrag 1204138)

2) Konzept überarbeiten ist leider nicht möglich, weil unsere komplette Anwendung so funktioniert.

Tut sie offensichtlich nicht...

[Caps]

Zitat:

Zitat von Uwe Raabe (Beitrag 1204153)

Zitat:

Zitat von Caps (Beitrag 1204138)

2) Konzept überarbeiten ist leider nicht möglich, weil unsere komplette Anwendung so funktioniert.

Tut sie offensichtlich nicht...

Das ist spitzfindig aber (momentan) korrekt. :thumb:

Hast Du vllt. ne Idee, wie ich aus der Message (TMsg.Message) irgendwas herauslesen kann, was mich weiterbringt? Also ich bin im Besitz der Message, welche den Fehler auslöst, jetzt muss ich nur noch herausfinden, was genau der Fehler ist, und wo er ausgelöst wird...

Wie gesagt: näher als bis zu "PeekMessage" komme ich leider nicht heran, es ist zum Tyrannosaurusmelken.

Edit:

Ich meine: wie kann ich aus einer TMsg-Nachricht was rauslesen, nicht nur aus TMsg.Message...

[DSCHUCH]

ist das nur bei handlemessage, oder auch bei processmessage?

[Caps]

Auch bei ProcessMessages leider :|

Edit:

Und ich muss korrigieren: es tritt auch auf, wenn ich auf das Panel klicke (s. Ursprungsposting)...

[DSCHUCH]

Gibt es evtl Timer, die vielleicht zuschlagen? Ist es beim ersten Durchlauf, oder bei einem zufälligen?

[Caps]

Auf der betreffenden Form ist kein Timer.
Mit Durchlauf meinst Du den Schleifendurchlauf? Da ist es beim Debuggen mit ziemlicher Sicherheit der erste Durchlauf nachdem ich auf das Formular geklickt habe.
D.h. ich drücke F9 und habe einen Breakpoint auf der Zeile "if PeekMessage(...". Da kann ich so oft F9 drücken wie ich will, alles bleibt ok. Dann klicke ich auf die eingefrorene Form und ziehe die Maus wieder heraus. Die Ausführungsposition steht auf der betreffenden Zeile. Wenn ich jetzt F8 drücke, kommt der Fehler.

[Bummi]

Du schließt das Fenster nicht zufällig per Free?

[Caps]

Das aktuelle Fenster (auf das ich klicke) ist noch offen, es soll eigentlich durch einen Button geschlossen werden, der die Prozedur Close enthält, aber wie gesagt: ein Klick irgendwo auf ein Control der Form produziert den Fehler, da ist von Schließen der Form noch keine Rede.

[DSCHUCH]

Aber es gibt kein OnClick Ereignis, welches da zufällig oder ausversehen irgendwo hängt? oder OnActivate, OnPaint?

Wie gesagt - Application.ÜrocessMessages ist eine der dümmsten Erfindungen in Delphi, kann man auch überall nachlesen, ganz klar meine Meinung... daher ja auch meine Frage in dem anderen Thread welches Entwurfsmuster denn nun eigentlich ideal für solche Fälle ist...

Edit: Hinweis - egal wo Timer sind, diese werden duch Application.....Messages immer ausgeführt, wenn diese fällig sind. Und der Timer wird über die Nachrichtenwarteschlange gesteuert. (Widerspricht aber Deiner Aussage, das es immer beim Click passiert)

[Caps]

Es gibt ein OnShow und ein OnCreate, die vorher auftreten (sollten).
Da kann ich auch mal schauen, ob die durchlaufen.

Über ProcessMessages weiß ich nicht viel, aber wir benutzen es, um die Forms "modal" anzuzeigen; der Dialoggraph ist ein "LIFO-Baum" (nenn' ich's mal...) - ich hab das noch nicht richtig verstanden, aber es funktioniert sonst ganz gut ;-).

Edit:

Das Panel, auf das ich immer klicke, hat kein Ereignis... (auf Deine Frage nach OnClick)

Edit2: LIFO, nicht FIFO!

[stahli]

ProcessMessages arbeitet ja nur die Nachrichten in der Warteschlange ab.
Insofern müsste ein Debuging möglich sein, wenn es in Deinem Quelltext knallt.

Offenbar tritt das Problem aber unter Windows-Kontrolle auf. Dann wird ein Debuging schwer.

Ich kenne das Problem, wenn ich ein Control aus meinem Framework heraus frei gegeben habe, das aktuell den Focus hatte. Den Focus haben ich einem anderen Control zugewiesen und das AltFocus-Control frei gegeben. Alles war gut, aber Windows meinte nach getaner Arbeit (wenn es wieder die Kontrolle übernommen hatte), das Control nochmal ohne Focus neu zeichnen zu müssen.
Meine Lösung: FocusControl unsichtbar setzen und später freigeben.

Ich tippe, dass Du auch etwas frei gibst, für das später noch eine Nachrichtenschlange abgewickelt wird.
ProcessMessages sollte man sehr sparsam verwenden (am besten gar nicht), da der eigene Programmablauf dadurch zeitlich nicht mehr vorhersehbar ist.

[Caps]

Zitat:

Hinweis - egal wo Timer sind, diese werden duch Application.....Messages immer ausgeführt, wenn diese fällig sind. Und der Timer wird über die Nachrichtenwarteschlange gesteuert. (Widerspricht aber Deiner Aussage, das es immer beim Click passiert)

Ja, stimmt, aber es passiert wirklich nur beim Klick oder beim Tastendruck, es gibt einen Timer auf einer anderen Form, aber die ist schon geschlossen...

[Caps]

Danke auch stahli für die Antwort. Ich glaube ich hab die Schnauze voll, und werde einfach mit Auskommentieren anfangen... :roll:

[stahli]

Vielleicht hilft Dir eine Trial von EurekaLog.
Bin aber nicht sicher, ob es noch eine Version für D5 gibt.

[CCRDude]

Wollte auch gerade madExcept empfehlen... etwas ähnliches in grün.

[Caps]

Interessant, kenne ich bisher noch nicht. Muss ich mal anschauen. Scannen die die Objektstruktur einer Anwendung oder so ähnlich...? Spannend, ich muss bloß mal zu Potte kommen.

[DSCHUCH]

Vermutlich wird es dann bei der WndProc knallen, wie bei meinem Test von letzter Woche - WM_KILLFOCUS auf ein freigegebenes Objekt (inkl Ausführen von Folgecode weiterer freigegebener Objekte), was auch Strahlis bsp nahelegen würde.

[Caps]

Zitat:

Zitat von DSCHUCH (Beitrag 1204184)

[...] WM_KILLFOCUS auf ein freigegebenes Objekt [...]

Na dann hätte ich ja mein Objekt ;-)

[sx2008]

Zitat:

Zitat von stahli (Beitrag 1204179)

Vielleicht hilft Dir eine Trial von EurekaLog.

Zitat:

Zitat von CCRDude (Beitrag 1204180)

Wollte auch gerade madExcept empfehlen... etwas ähnliches in grün.

In der JCL gibt es Klassen, mit denen man ebenfalls einen Stacktrace erzeugen.
Die JCL ist Open Source und sehr empfehlenswert. Beispielprojekt StackTrackExample.dpr

[Caps]

Ok, danke erstmal Leute, ich hab momentan doch angefangen, auszukommentieren.
Ich sag bescheid, was es nun endlich war.

Danke nochmal allen!
Das mit den StackTracern ist ne tolle Sache, wenn ich Zeit hab, probiere ich die mal aus.

Beste Grüße
Caps

[generic]

Ich möchte noch einmal auf das ShowModal zurück kommen.

ShowModal macht doch auch nichts anderes, als was deine Schleife macht.
Nachrichten so lange behandeln, bis im Form das ModalResult gesetzt ist.

Ich kann derzeit nicht erkennen, warum das nicht bei deinen Projekt funktionieren soll.
Kann du das bitte erläutern.

[Caps]

Ehrlich gesagt weiß ich nicht, warum die GUI auf diese Weise erstellt wurde, ich habe mich da einfach nur angepasst :-). War das Verschachteln von modalen Fenstern schon immer möglich? Wenn nicht, dann könnte es damit zusammenhängen, dass die GUI für diesen Zweck so gebaut wurde. Ansonsten ist es vielleicht einfach noch ein Design-Relikt aus DOS-Zeiten, keine Ahnung... :angel2:

Grüße
Caps

[Caps]

:idea:

Problem gelöst.

Es war (wie zu erwarten) ein -fast- selbstgemachtes Problem. Wir verwalten unsere Forms in einem Array. Und durch ein simples Vertauschen von Aufrufen habe ich einen ungültigen Array-Index angesprochen. Verwirrend war halt nur, dass die Exception in der Message-Schleife geschmissen wurde. Der Rest ist Nudelsalat... :cheer:

Es grüßt herbstlich
Caps

[sx2008]

Zitat:

Zitat von Caps (Beitrag 1204751)

Wir verwalten unsere Forms in einem Array.

Ich würde das auf Listen (z.B. TObjectList) umstellen.
Listen sind für diese Aufgabe einfach besser geeignet.

[Caps]

Das wäre wahrscheinlich sinnvoll.

lg Caps