Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Zugriffsverletzung bei Application.HandleMessage (https://www.delphipraxis.net/173336-zugriffsverletzung-bei-application-handlemessage.html)

Caps 18. Feb 2013 12:16

Zugriffsverletzung bei Application.HandleMessage
 
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 18. Feb 2013 12:23

AW: Zugriffsverletzung bei Application.HandleMessage
 
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 18. Feb 2013 12:29

AW: Zugriffsverletzung bei Application.HandleMessage
 
Warum nutzt du nicht
Delphi-Quellcode:
form.showmodal
?
Dann brauchst du die Schleife nicht.

Caps 18. Feb 2013 12:36

AW: Zugriffsverletzung bei Application.HandleMessage
 
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 18. Feb 2013 13:16

AW: Zugriffsverletzung bei Application.HandleMessage
 
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 18. Feb 2013 13:20

AW: Zugriffsverletzung bei Application.HandleMessage
 
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 18. Feb 2013 13:24

AW: Zugriffsverletzung bei Application.HandleMessage
 
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 18. Feb 2013 13:29

AW: Zugriffsverletzung bei Application.HandleMessage
 
ist das nur bei handlemessage, oder auch bei processmessage?

Caps 18. Feb 2013 13:33

AW: Zugriffsverletzung bei Application.HandleMessage
 
Auch bei ProcessMessages leider :|

Edit:

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

DSCHUCH 18. Feb 2013 13:38

AW: Zugriffsverletzung bei Application.HandleMessage
 
Gibt es evtl Timer, die vielleicht zuschlagen? Ist es beim ersten Durchlauf, oder bei einem zufälligen?


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:32 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz