AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi PostMessage: Objekte "verschicken" führt zu Access Violation
Thema durchsuchen
Ansicht
Themen-Optionen

PostMessage: Objekte "verschicken" führt zu Access Violation

Ein Thema von s.h.a.r.k · begonnen am 4. Mär 2011 · letzter Beitrag vom 4. Mär 2011
 
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#10

AW: PostMessage: Objekte "verschicken" führt zu Access Violation

  Alt 4. Mär 2011, 13:16
Erst mal vielen Dank für die Antworten! Dann fangen wir mal ganz oben an:

Was das Senden angeht: keinen Pointer darauf (doppelt gemoppelt), sondern das Objekt selbst: PostMessage(FModuleHandles[i], APM_LOG_MESSAGE, Integer(ClonedMsg), 0);
Werde ich gleich testen und dann Bericht erstatten.

ausserdem würde ich nicht wParam, sondern lParam benutzen. Oder ist Word seit neuestem 32Bit gross ?
Seit geraumer Zeit ist selbst WPARAM ein Integer. Habe sogar im Source-Code der VCL nachgeschaut, da ich da auch einen Fehler vermutet hatte. Aber wie schon erwähnt: es kommt der richtige Pointer in der Recieve-Methode an, ganz ohne Zweifel!

Was sind das für Module? Befinden sie sich in einem eigenen Prozess? Dann hat der Empfänger evtl. einfach keinen Zugriff auf den Speicherraum des Senders.
Die Module werden bisher im selben Prozess und im selben Thread erzeugt! Unter Module verstehe ich eine Klasse, die von einer Grundklasse abgeleitet, die Logs entgegennimmt und verarbeitet, z.B. TApLogFileModule schreibt die eingehend Log-Messages in eine Datei.

Versuche es mal mit SendMessage. Da damit die Ausführung direkt durchgeführt wird, sind die lokalen Variablen der aufrufenden Funktion noch vorhanden. Bei PostMessage sind diese meist schon wieder aufgeräumt, da du .Free aufrufst, bevor die Nachricht überhaupt ankam.
Habe doch schon erwähnt, dass ich auf SendMessage verzichten will Der Vollständigkeit halber hier noch die Begründung: ich will nicht, dass meine Log-Klasse anderen Code blockiert und evtl. ausbremsts. Daher will ich, dass die Module erst dann mit der Verarbeitung beginnen, wenn weiter Nachrichten verarbeitet werden. Somit sollte es weniger blockierend sein.

Und nein, ich rufe Free nur auf dem Original-Objekt auf, nicht auf den geklonten Versionen!

Delphi-Quellcode:
...
  finally
    OriginalMsg.Free();...
... also als wäre es freigegeben worden. Aber das geschieht nirgends! Ich habe das mind. 5 mal geprüft.
*rofl* An der Stelle musste ich echt lachen

Mit records würde das funktionieren, ansonsten darfst du das Objekt nicht freigaben wenn du es noch verwenden willst! Bist du nen GC gewohnt?
Tja, nur zerstöre ich hier ein Objekt, welches wirklich freigegeben werden soll Schau mal -- wie Bummi
schon bemerkt hat -- in die SendToModules() Methode. Dort klone ich die Log-Message genau so oft, wie ich registrierte Module habe. Somit bekommt jedes Modul sein eignes Log-Message-Objekt.

Was meinst du mit GC? GNU Compiler? Games Convention?

@himi: Wenn man ein Objekt erzeugt, sollte das aber doch eigentlich auf dem Heap geschehen, also sollte das eigentliche Objekt (sofern man es nicht freigibt) doch auch nach der Funktion vorhanden sein, oder?
Davon ging ich aus. Aber aus irgendeinem Grund scheint das Objekt nicht mehr zu existieren. Daher meine Befürchtung, dass genau der Speicherbereich aufgeräumt oder überschrieben wurde.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:05 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz