The one and only 'WndProc' ?
-
Wenn jedes Childwindow seine eigne Meldungsverarbeitungschleife hat wie ist es dann möglich dass der Parent WM_COMMAND erhält? Du behauptest (was wahrscheinlich auch richtig) ist dass jedes Fenster seine eigne Botschaftsverarbeitung hat(eine von Windows generierte) aber wieso erhaltet den dann mein Hauptfenster dieses WM_COMMAND ???
-
Das Dialogfenster verarbeitet die Nachrichten (WM_KEYDOWN, WM_MOUSEMOVE und ähnliche) selber - als Resultat kann es durchaus eigene Nachrichten wie WM_COMMAND weiterschicken.
PS: Bitte nicht schreien, damit machst du dich nur unbeliebt.
-
japs, genau, bin direkt beleidigt #gg
stell dir vor ein button wuerde das klick nicht selber verarbeiten, muesste der parent dann sagen "zeichne dich gedrueckt, zeichne ein rahmen, blinke noch n bissl rum, zeichne nicht gedrueckt" #gg
jede aktion eines fensters {auch wenns nur ne mausbewegung darueber ist {da es dann neu gezeichnet werden muss} oder ein focus wechsel, behandelt jedes fenster fuer sich, und sended bei bedarf {zb bei einem klick} eine message an das parent
this->GetParent()->SendMessage(WM_CLICK, MyId, lParam); usw usw
-
C-Chris schrieb:
Wenn jedes Childwindow seine eigne Meldungsverarbeitungschleife hat wie ist es dann möglich dass der Parent WM_COMMAND erhält? Du behauptest (was wahrscheinlich auch richtig) ist dass jedes Fenster seine eigne Botschaftsverarbeitung hat(eine von Windows generierte) aber wieso erhaltet den dann mein Hauptfenster dieses WM_COMMAND ???
Weil zur Standardprozedur der ChildWindows eben der Befehl "SendMessage (hParent, WM_COMMAND)" (oder so ähnlich) gehört.
-
jedes fenster hat eigene prozedur
Jungs, jetzt mal ne' ganz andere Frage dazu:
Wenn schon jedes Fenster (Button, TreeView, Liste, etc.) eine eigene Prozedur hat, wie heißt denn die z.B. standardmäßig beim Button ?
Ich meine - wenn ich gerade keinen Bock darauf habe für MEIN Fenster eine Nachricht zu implementieren, so kann ich einfach DefWindowProc() aufrufen.
Aber wie heißt die Funktion unter Windows, die für meinen Button die Nachrichtenbehandlung standardmäßig durchführt ? Hat da jemand eine Ahnung von ?Greetings, Xzi-bit
-
Das "Pendant" zu DefWindowProc () heißt CallWindowProc (). Den "pPrevWndFunc" erhält man z.B. durch GetClassInfoEx (...,"BUTTON",...).
Der Einsatz dieser Funktionen ist aber nur sinnvoll wenn der Button gesub- oder superclassed wurde.
-
Ok, danke. Ich hab übrigens die zugehörigen internen Windows-Funktionsnamen gefunden. Die Windows-interne 'WndProc' für einen Button lautet 'ButtonWndProc', die für eine CheckListe 'CheckListWndProc', usw. usf.
Danke an Alle nochmals
Greetings, Xzi-bit
-
Mr Evil schrieb:
japs, genau, bin direkt beleidigt #gg
stell dir vor ein button wuerde das klick nicht selber verarbeiten, muesste der parent dann sagen "zeichne dich gedrueckt, zeichne ein rahmen, blinke noch n bissl rum, zeichne nicht gedrueckt" #gg
jede aktion eines fensters {auch wenns nur ne mausbewegung darueber ist {da es dann neu gezeichnet werden muss} oder ein focus wechsel, behandelt jedes fenster fuer sich, und sended bei bedarf {zb bei einem klick} eine message an das parent
this->GetParent()->SendMessage(WM_CLICK, MyId, lParam); usw usw
Tut mir direkt Leid. Habe es rückgäning gemacht.
-
CStoll schrieb:
Das Dialogfenster verarbeitet die Nachrichten (WM_KEYDOWN, WM_MOUSEMOVE und ähnliche) selber - als Resultat kann es durchaus eigene Nachrichten wie WM_COMMAND weiterschicken.
PS: Bitte nicht schreien, damit machst du dich nur unbeliebt.
Dann hat mein Buch wohl doch nicht gelogen. Dann ist das garkein so grosser "Quatsch".
Zum "schreien": Hat aufgehört-
-
Mr Evil schrieb:
jedes fenster hat eigene prozedur
fuer ein button zb ware im paint das zeichnen des textes, farbverlauf usw, das hast du in deiner main prozedur nicht da sich jedes fenster um sich selber kuemmert
subclassing lohnt sich immer dann wenn du an eine message willst welche nicht ans parent weiter geleitet wirdMr Evil hat ausserdem auch gesagt dass die Botschaften an den Parent weitergeleitet werden.