WM_APPCOMMAND - Nur benötigte Commandos abfangen?!

[nicodex]

Zitat:

Zitat von sirius

:gruebel: bei mir (D7) gibt es keine inhertied Methode mit WM_APPCommand, aber wenn es funktioniert....

Der Compiler macht was nötig ist, ohne den Entwickler mit den Details zu nerven (wenn es eine gibt, dann wird sie auch aufgerufen).

[sirius]

Ich wollte ja nur grad nachsehen, was dort gemacht wird. Aber ich habe keine Methode gefunden.

[nicodex]

Zitat:

Zitat von sirius

Ich wollte ja nur grad nachsehen, was dort gemacht wird. Aber ich habe keine Methode gefunden.

Haltepunkt setzen und das CPU-Fenster öffnen (normalerweise [Strg+Alt+C]).

ps: "..., call dword ptr [ecx-$10]" ist "DefaultHandler(Msg)".

[sirius]

Dazu müsste ich erstmal das Programm schreiben.

inherited (für Messages) ist im Standardfall der Defaulthandler? Ist ja eine ganz neue Erkenntnis.


Edit: Das ist ja interessant. Das musste ich jetzt doch einmal durchtesten. Der Defaulthandler wird schon in TObject als virtuelle Methode deklariert und wird für Message-Methoden (welche ja dynamisch sind) immer bei inherited aufgerufen. Weiß nicht, ob das so bekannt ist. Mir war es nicht bekannt. Denn bisher wusste ich nur, dass ein inherited nur ausgeführt wird, wenn:

• bei statischen oder virtuellen Methoden eine Vorfahrklasse eine Methode mit gleichem Header+Name hat
• bei dynamischen Methoden eine Vorfahrklasse eine Methode mit gleichem Header+ (Index bzw. Name) hat

Message-Methoden sind ja dynamische Methoden bei denen man den Index über die Konstante (e.g. WM_User) vorgibt (Deswegen lassen sie sich ja mittels Dispatch so leicht auffinden). Sie haben aber noch den Unterschied zu anderen dynamsichen Methoden, dass ein Vorfahr immer der Defaulthandler ist. Und das von jeder Message-Methode.

==>Also neben der Methode Dispatch ist auch noch die Methode DefaultHandler (beide von TObject implementiert) wichtig für Message-Methoden.

[nicodex]

Zitat:

Zitat von sirius

inherited (für Messages) ist im Standardfall der Defaulthandler?

Jupp. Die Funktion ist übrigens virtuell, damit man sie überschreiben und Nachrichten behandeln kann, die keine festen Nachrichten-IDs haben (RegisterWindowMessage).
"inherited" ist die beste Lösung, da der Compiler sich darum kümmert, was aufgerufen werden muss.
Bei WM_ACTIVATE wäre es (in meiner Delphi-Version) TCustomForm.WMActivate() - aber das braucht den Entwickler nicht zu interessieren (und kann sich auch von Delphi-Version zu Delphi-Version ändern). Würdest du DefWindowProc() aufrufen, dann würdest du die "Vererbung" aufbrechen und diverse Handler übergehen.

[sirius]

Ich hab das nochmal in meinem Edit zusammengefasst. Das ist ein etwas anderes Verhalten als ich von inherited erwartet hätte. Das kann man ja in Zuklunft sicher gewinnbringend einsetzen.

[chri_ri]

Hm ist ja interessant. Also ist inherited; die beste Lösung, weil die dem Compiler mehr Spielraum lässt um die optimalere Lösung zu finden. Ok, habe sowieso inherited genommen, schon weils einfach "smaller" ist. Aber ertsmal Thx für die Zusatzinfo am Rande.



mfg. chri_ri