Zugriffsverletzung bei Application.HandleMessage

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

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