DispatchMessage

Question

Hey Leute,

ich lese im Moment das Buch Windows Programmierung von Charles Petzold, da ich mich mit der Programmierung mittel C++ und WIN-API beschäftigen mag.

So und ich dachte eg die Funktion DispatchMessage, leitet eine Nachricht an die enstsprechende Window-Prozedur weiter und mehr nicht.

Ich dachte dass der Empfänger der Nachricht, also der HANDLE beim Senden der Nachricht angegeben wird( ist ja auch so ).

 

Jedoch lese ich in dem Buch folgenden Text, ich zitiere mal kurz:

Bei Nachrichten jeder Art bezeichnet der Parameter hwnd bzw. das gleichnamige Feld einer MSG-Struktur den Fensterhandle des Empfängers. Besetzt wird dieses Feld erst im Rahmen von DispatchMessage. Dort sorgt Windows dafür, dass dieser Fensterhandle grundsätzlich der <<richtige>> ist.

 

Das verstehe ich jetzt nicht so ganz?

 

Vielleicht kann mir das mal jemand kurz erläutern.

Wäre echt toll.

 

Lg freeG

Answer 1

Mal etwas konstruiert, aber zum Verständnis:
In der Theorie soll ein Fenster eine Nachricht bekommen (z.B. Maus-Move), da aber aufgrund bestimmter Flags im Fenster (transparent) dieses Fenster diese nicht will, kann DisptachMessage mit der Nachricht sehr wohl was anderes machen. Sie z.B. an das darunter liegende Fenster leiten...

DispatchMessage sorgt zum Beispiel auch dafür, dass fensterlose Timer augerufen werden...

DisptachMessage eben doch mehr als nur ein SendMessage...

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 2

Am 03.09.2010 16:53, schrieb fr33g:

Hey Leute,

ich lese im Moment das Buch Windows Programmierung von Charles Petzold, da ich mich mit der Programmierung mittel C++ und WIN-API beschäftigen mag.

Vergiß Petzold! Dessen Stil (riesige Käsefabriken von Message Vearbeitungen) ist ist schon seit mindestens 15 Jahren veraltet und wirklichen Einblick in die interne Funktion von Windows bekommst du damit auch nicht. Kein Mensch programmiert heute mehr so. Setz den Schwerpunkt lieber auf objektorientierte Programmierung.

Hajü

Answer 3

> Vergiß Petzold! Dessen Stil (riesige Käsefabriken von Message Vearbeitungen) ist ist schon seit mindestens 15 Jahren veraltet und wirklichen Einblick in die interne Funktion von Windows bekommst du damit auch nicht. Kein Mensch programmiert heute mehr so. Setz den Schwerpunkt lieber auf objektorientierte Programmierung.

Das kann ich nicht unterschreiben.
Die Windows API funktioniert immer noch so, wie dort beschrieben. Dito GDI etc.

Es hilft in jedem Fall zum verstehen!
Schaden kann es nicht. Ich würde sogar eher sagen, nur OOP macht gar nichts besser und weil man keine Hintergründe kennt läuft man in 1000 Fallen... ;)

Ich könnte wüsste aktuell keinen guten Rat, wie man in die native Windows Entwicklung einsteigt. Der Weg wie ich es selbst nur lernen konnte: damals Win32 pur, dann irgendwann MFC, COM, ATL (so etwa in der Reihenfolge) war schon OK.

Unabdingbar: Sattelfestigkeit in der Sprache C/C++ selbst.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 4

Am 03.09.2010 20:45, schrieb Martin Richter [MVP]:

Vergiß Petzold! Dessen Stil (riesige Käsefabriken von Message Vearbeitungen) ist ist schon seit mindestens 15 Jahren veraltet und wirklichen Einblick in die interne Funktion von Windows bekommst du damit auch nicht. Kein Mensch programmiert heute mehr so. Setz den Schwerpunkt lieber auf objektorientierte Programmierung.

Das kann ich nicht unterschreiben.
Die Windows API funktioniert immer noch so, wie dort beschrieben. Dito GDI etc.

Das tut sie, aber die Beispiele dort benutzen immer Unmengen an globalen Variabelen und die sind das reinste Gift in der Programmierung weil sie zu tückischen Seiteneffekten verleiten, die irgendwann bei größeren Programmen nicht mehr zu überschauen sind. Und wenn man sich den Stil erst mal angewöhnt hat ist es schwer ihn wieder abzulegen.  Anfänger denken vielleicht das ist state-of-the-art in Windows Programmierung und das ist es nicht.

Es hilft in jedem Fall zum verstehen!
Schaden kann es nicht. Ich würde sogar eher sagen, nur OOP macht gar nichts besser und weil man keine Hintergründe kennt läuft man in 1000 Fallen... ;)

Ich finde ein Kapitel reicht IMHO für die Grundlagen, dafür lernt man bei OOP seine Objekte zu kapseln. Alles Andere wird früher oder später Spaghetticode.

Ich könnte wüsste aktuell keinen guten Rat, wie man in die native Windows Entwicklung einsteigt. Der Weg wie ich es selbst nur lernen konnte: damals Win32 pur, dann irgendwann MFC, COM, ATL (so etwa in der Reihenfolge) war schon OK.

Ich auch, aber den Petzold-Stil loszuwerden war nicht einfach. Wenn er heute einen anderen Stil propagiert, nehme ich alles zurück

Unabdingbar: Sattelfestigkeit in der Sprache C/C++ selbst.

ACK

Hajü

Answer 5

Also gute C/C++ Kenntnisse hab ich schonmal=)

Daher wollte ich mich nun auch mal mit GUI und anderen Dingen wie Netzwerkprogrammierung beschäftigen.

Ich fing mal kurz mit Qt an, das gefiel mir jedoch gar nicht, hab dann mir kurz mal die MFC angeschaut und hab mich dann aber eben doch für die Win-API entschieden.

Also mir wurde mehrfach dieses Buch empfohlen, ich persönlich find es auch sehr gut, wobei ich auch nicht alles soübernehme sondern schon meinen eigenen Stil nutze, wie zum Beispiel Vektoren nutze statt Arrays std::string wo es möglich ist. Genauso vermeinde ich wenn möglich globale Variablen( wobei ich bisher im Buch kaum welche gesehen habe, es gibt manche die vielleicht unnötig früh deklariert sind( was ich dann auch anders mache ) aber globale sehe ich kaum ). Aber ich finde so um die Win-API kennen zu lernen und auch zu nutzen ist das Buch echt spitze. Ist nur schade dass es keine neuere Auflage gibt wo es um die GDI+ statt GDI geht.

Was würdest du mir denn dann empfehlen um in die Win-Api einzusteigen?

Und ja ich kenn schon ein paar Leute die sehr wohl mit der Win-API programmieren. Man hat wie ich finde viel mehr Möglichkeiten, auch wenn es oftmals mit einer OOP-Bibliothek leichter wäre. Jedoch kann man sich die Teile der Win-API die man oft braucht auch selber in Klassen kapseln. Mir macht es mit der Win-API einfach viel mehr Spaß als mit so nem fertigen Framework wie Qt. Daher würde ich auch gern erst mal bei der in-API bleiben.

 

Lg freeG

Answer 6

Am 03.09.2010 22:46, schrieb fr33g:

Was würdest du mir denn dann empfehlen um in die Win-Api einzusteigen?

Da kann ich dir leider auch keinen Rat geben, bei mir ist das schon lange her. Aber die MFC ist doch gerade im Bereich GDI oder der Implementierung von CWnd nur ein hauchdünner Wrapper der Winapi ohne daß man mit diesen schlimmen Käsefabriken (case-Blöcke) in Kontakt kommt. Die Klassenmethoden heißen oft genauso wie die korrespondierenden API Funktionen.

Ich kenne QT jetzt nicht aber die hat ganz sicher einen wesentlich höheren Abstraktionsgrad weil sie ja auch kompatibel zu Linux und Mac seien muss.

Und ja ich kenn schon ein paar Leute die sehr wohl mit der Win-API programmieren. Man hat wie ich finde viel mehr Möglichkeiten, auch wenn es oftmals mit einer OOP-Bibliothek leichter wäre. Jedoch kann man sich die Teile der Win-API die man oft braucht auch selber in Klassen kapseln. Mir macht es mit der Win-API einfach viel mehr Spaß als mit so nem fertigen Framework wie Qt. Daher würde ich auch gern erst mal bei der in-API bleiben.

Wenn du es schaffst nicht die Struktur aus den Augen zu verlieren, dann mag es ja gehen, aber Viele laufen mit dem Stil ins offene Messer. Ich hatte früher mal zwei Kollegen, die sind mit einem für damalige Verhältnisse ziemlich umfangreichen Projekt in dem Stil hoffnungslos versandet. Da war ich froh, dass ich damit nichts zu tun hatte. Anfang der '90er war das, Windows 3.1. Später haben sie geschwärmt, wie toll Delphi ist ;)

Hajü

Answer 7

Nimm ACE für die Netzwerkprogrammierung.

Das Buch von Petzold ist genau das richtige um mit der winapi anzufangen. Wenn Du begriffen hast, was unter der Haube steckt und wie Nachrichten und Betriebssystemressourcen funktionieren, solltest Du aber trotzdem irgendetwas verwenden, was Dir das Leben einfacher macht.

Z.B. wenn Du flotten Code mit viel oop willst lohnt der direkte Schwenk zu ATL/WTL. Das mag alles nicht sog. "state of the art" sein, ist aber der beste Kompromiss für Leute mit guten C++-Kenntnissen.

MFC ist super und ich verwende es sehr gerne, aber es hat auch viele Macken, die seit Jahren nicht gelöst werden, wie das Theater mit den voreingestellten Lecks im CHTMLView und den umständlichen Socketklassen. Dafür ist es gut gepflegt und bietet enorme Erleichterungen und es gibt abertausende Beispielcodes sowie kommerzielle Bibliotheken für praktisch jeden Anwendungsfall.

Sobald WTL nicht mehr genug für Dich ist und Du etwas wie MFC brauchst, wirst Du nicht mehr hier fragen müssen um auf die Idee zu kommen. ;-)