Was passiert in DispatchMessage genau?
-
DispatchMessage sendet ja eine Nachricht an die jeweilige Window-Procedure. Ich möchte jetzt aber anhand der Message selbst bestimmen, wie verfahren werden soll. Also, mit GetMessage() hole ich mir die aktuelle Nachricht, und bearbeite sie selbst direkt in meinem Message-Loop, bzw. reiche sie selbst an eine Funktion weiter. Meine Frage ist jetzt: Macht DispatchMessage() irgendetwas, was mir bei meiner Methode fehlen würde? Irgenwelche wichtigen Aktionen? Denn soweit ich das überblicke, bräuchte man theoretisch man gar kein DispatchMessage() solange man die Nachrichten in der Nachrichtenschleife selbst bearbeiten will.
-
Im Sourcecode von Wine kannst du sowas zum Beispiel nachgucken: http://source.winehq.org/source/dlls/user32/message.c
-
Danke, das sieht ja gar nicht schlecht aus.
Wobei ich nicht wirklich nachvollziehen kann, was da genau passiert. Auf jeden Fall frage ich mich gerade, wie es um den Return-Wert der Window-Procedure aussieht. Dabei handelt es sich ja um ein LRESULT. In der MSDN steht, dass dieser Wert auch vom DispatchMessage()-Aufruf zurückgegeben, dort aber verworfen wird.Was ich mich jetzt Frage: bekommt den Wert Windows zwischendrin noch irgendwie überreicht? Falls dieser Relevant wäre, wäre mein Plan schon so gut wie gescheitert, ich kann aus meiner Nachrichtenschleife ja schlecht einen Wert zurück geben...
-
Für mich ist eher die Frage: Warum machst Du das?
Die ganze Geschichte spielt sich sowieso hier nur für die Nachrichten ab die in die Queue eingestellt werden.
Ansonsten ist DisptachMessage eher eine ziemlich "einfache" Funktion und hat IMHO keine erweiterte Funktion außer eben die Windows Prozedure aufzurufen.
-
Warum ich das mache:
So könnte ich relativ einfach eine Klasse bauen, die die Nachrichten-Bearbeitung übernimmt, bzw. die Nachrichten an bei ihr registrierte Fensterklassen verteilt. Der DispatchMessage-Aufruf wäre da nur ein unnötiger Zwischenschritt, denn dann müsste ich in meiner Window-Procedure wieder auf die Klasse zur Nachrichtenverteilung zugreifen. Das verursacht nur Probleme und ist umständlich.
-
Ich rieche einen Designfehler.
MfG SideWinder
-
SideWinder schrieb:
Ich rieche einen Designfehler.
MfG SideWinder
Jupp! Agree...
@MessageDispatcher: Du hast noch nciht verstanden was Klassen und Fensterklassen sind und wie man die in C++ Klassen (unter Beibehaltung von DisptachMessage) prima verwalten kann.
-
Naja, habt ihr dann zumindest auch eine Erklärung oder einen Link für mich?
-
Nunja, mein System hat den Nachteil, dass Nachrichten die direkt an die Window-Procedure gesendet werden, (natürlich) nicht ankommen können, bzw. dadurch ein Laufzeitfehler ausgelöst wird, wenn man in der WNDCLASS-Struktur keine Dummy-Funktion angibt, bzw. DefWindowProc.
Aber wo liegt da ganz konkret der Designfehler? An sich finde ich das Konzept nicht wirklich schlecht, bis auf den eben genannten Nachteil.
Martin Richter schrieb:
@MessageDispatcher: Du hast noch nciht verstanden was Klassen und Fensterklassen sind und wie man die in C++ Klassen (unter Beibehaltung von DisptachMessage) prima verwalten kann.
Haben wir uns hier vllt. auch missverstanden? Also ich meinte mit Fensterklasse eine C++ Klasse, die in meiner Anwedung ein Fenster repräsentiert (keine WNDCLASS).
-
Ja und?
Deswegen brauche ich doch DispatchMessage nicht erstezen, um die Nachrichten korrket and die Fensterklassen auszuliefern.
Das eigentliche Problem entsteht dann wenn Du sie nicht an die Fensterprozedur auslieferst. Denn dan werden einige Mechanismen die danach kaskadierend und zum Teil Rekursiv SendMessage auslösen nicht mehr funktionieren.Was glaubst Du denn we C++ Konstrukte wie die MFC und ATL und WTL arbeiten?
Diese ersetzen in keinem Fall DispatchMessage.
Der Designfehler liegt darin, einen vorgeschriebenen dokumentierten WinAPI Konstrukt zugunsten eines eigenes Design auszuhebeln oder zu ersetzen.
Ich bezweifle grundsätzlich solches Vorgehen...
-
Martin Richter schrieb:
Der Designfehler liegt darin, einen vorgeschriebenen dokumentierten WinAPI Konstrukt zugunsten eines eigenes Design auszuhebeln oder zu ersetzen.
Nungut, das habe ich allerdings keinesfalls bewusst gemacht. Deshalb wollte ich hier ja jetzt auch nachfragen, wozu man DispatchMessage genau braucht. Es könnte ja sein, dass DispatchMessage nur eine Hilfsfunktion ist, um die Window-Procedure für die jeweilige Nachricht aufzurufen, die sonst nichts macht. Und das es so ist, meintest du einige Postings zuvor auch noch.
Denn dann könnte ich das ja auch direkt selbst machen. Ich sage, DispatchMessage erleichtert sicher die Programmierung von Anwendungen in C, in meinem Fall verkompliziert sie aber einiges. Bzw. wusste ich nicht, dass DispatchMessage vorgeschreiben ist (Link?).Wie MFC, ATL und WTL arbeiten, weiß ich nicht.
-
MessageDispatcher schrieb:
Es könnte ja sein, dass DispatchMessage nur eine Hilfsfunktion ist, um die Window-Procedure für die jeweilige Nachricht aufzurufen, die sonst nichts macht.
Ganz so einfach ist das leider nicht. DispatchMessage sorgt z.B. dafür, daß eine WM_TIMER erst dann die Window-Procedure erreicht, wenn die Messagequeue "leer" ist (wird quasi zurückgehalten).
Je nach dem was bei WM_TIMER passieren soll, könnte es ungewollte Folgen für den Programmablauf haben, wenn es z.B. zwischen WM_KEYDOWN und WM_KEYUP abgearbeitet wird. Ohne dieses "Preprocessing" von DispatchMessage würden sich viele Anwendungen ungewollt seltsam benehmen.
-
Gut, danke für die Information. Aber ist auch schade...
Hmm, was mir jetzt noch einfallen würde, wäre ein Funktor, der der WNDCLASS übergeben wird. Aber wenn Windows die Methode zur Nachrichtenbehandlung dann über den Funktor aufruft, könnte es aber zu Problemen bei den ersten Nachrichten kommen, also WM_CREATE etc. Dann wird auf das Objekt schon zugegriffen, obwohl es gerade noch konstruiert wird.
Irgendwie vergeht mir jetzt die Lust, nach über einer Woche.
-
Das mit dem Funktor war natürlich Quatsch.
Ich weiß keine andere Möglichkeit mehr.Bleibt wohl kein anderer Weg, als ne statische Methode oder GetWindowLongPtr-Gefrickel, schade.
-
MessageDispatcher schrieb:
Das mit dem Funktor war natürlich Quatsch.
Ich weiß keine andere Möglichkeit mehr.Bleibt wohl kein anderer Weg, als ne statische Methode oder GetWindowLongPtr-Gefrickel, schade.
Bevor Du hier von Gefrickel redest, schau Dir mal an wie die MFC und besonders die ATL das angeht...
-
Mhmm, kannst du mir vielleicht eine kleine Starthilfe geben, wo ich das nachschauen kann, bzw. wo es vllt. sogar ein wenig erklärt wird. Ich hab mir mal ein MFC-Projekt angelegt, aber schon alleine was der AppWizard da erzeugt, erschlägt einen ja fast.
-
Nagut, ich hab mich mittlerweile ein wenig mehr reingewuselt. In den MFC ist das alles wirklich klasse schön, ganz ähnlich will ich das ja auch in meinem Programm. Aber mit den MFC will ich eigentlich für den Moment noch nicht arbeiten.
Wie die MFC das aber genau machen, kann ich nirgendwo finden. Das ist sowieso sowas von schwer nachzuvollziehen, was da passiert, weil man gar nichts mehr von der WinAPI sieht. Also falls ihr wissen solltet, wie das funktioniert, bzw. wo man die Funktionsweise nachlesen kann, sagt es mir bitte!
Ich werd jetzt noch bisschen weiter googlen und dann noch die MSDN durchforsten, wobei da zur Implementierung auch kaum was stehen wird. Auf jeden Fall Danke für die bisherige Hilfe.
-
Die MFC verwendet eine einzige zentrale WndProc (AfxWndProc). Jedes Fenster, dass erzeugt wird, bekommt diese WndProc zugeweisen und das Fenster selber wird in einem Map einegtragen, in der die eigentliche Klasse verzeichnet ist, die für das Fenster verantwortlich ist. Kommt also eine Fensternachricht rein wird die Map nach der Klasse gesucht und dort dann die virtuelle Member Funktion CWnd::WindowProc für die Fensterklasse aufgerufen. Dort wird dann die Nachricht übereine Message-Map intern an die Memberfunktionen verteilt.
-
Sehr schön, vielen lieben Dank!! Die zwei Konzepte zu kombinieren, darauf muss man auch erst kommen
-
Sehr gut, eine Frage wirft sich mir nun nur noch auf:
Werden Dialoge genau so behandelt? Vermutlich ja, aber auch über die AfxWndProc, oder gibt es dafür noch eine seperate DialogProc?
