Kann ich Windows-Messagehandler einer Form auslagern?

[Aphton]

Wie berits himitsu schrieb

Zitat von himitsu:

Delphi-Quellcode:

protected
  procedure WndProc(var Message: TMessage); override;

Konkreter:

Delphi-Quellcode:

TWindowsMessageHandler = class
   private
      procedure WMEnterSizeMove(var Message:TMessage); // kein TWMSize - du musst hier drinnen die Message dann auswerten
      // oder du befüllst eine TWMSize variable in handleMessage und übergibst es dieser Methode - dann ginge TWMSize -> aber handleMessage sollte nicht diese Aufgabe haben
      // jeder für sich.. 
      procedure WMExitSizeMove(var Message:TMessage);
      [...]         
   public
      procedure handleMessage(var Message: TMessage);
end; 

TSomeForm = class(TForm)
protected
  procedure WndProc(var Message: TMessage); override; 
private
  MyMsgHandler: TWindowsMessageHandler;
end:

(...)
TSomeForm.WndProc(var Message: TMessage);
begin
  inherited;
  MyMsgHandler.handleMessage(Message);
end;

Ganz einfacher Ansatz; diese Lösung reagiert aber auf alle Messages die das Fenster betrifft (die handleMessage Methode, welche ne Filterung nach Msg macht und intern die privaten Methoden aufruft, sollte daher recht flott sein, da die App sonst evt. stottert, weil handleMessage mehrere tausend Mal pro Zeiteinheit aufgerufen werden kann..)

[Der schöne Günther]

Danke Sirius, das war genau was ich wollte! Ich verstehe die Implementation von TObject.Dispatch(var Message) zwar nicht im Geringsten (so viel Assembler), aber es funktioniert traumhaft!

Ein Problem mit zirkulären Referenzen sehe ich in meiner kurzen Umsetzung nicht: Der Messagehandler muss doch nur in seniem implementation -Teilum die konkrete Klasse des Formulars wissen um beispielsweise eine Farbe oder einen speziellen Button darauf anzufassen.

[sirius]

Zitat von Der schöne Günther:

Ein Problem mit zirkulären Referenzen sehe ich in meiner kurzen Umsetzung nicht:

Ein Problem ist das auch nicht, wenn man eine Unit in den implemantationsteil als uses schreibt. Nur manche mögen das halt nicht...

[Zacherl]

Zitat von Der schöne Günther:

Ich verstehe die Implementation von TObject.Dispatch(var Message) zwar nicht im Geringsten (so viel Assembler)

Die habe ich mir auch vor kurzem zu Gemüte geführt.

Delphi-Quellcode:

procedure TObject.Dispatch(var Message);
type
  THandlerProc = procedure(var Message) of object;
var
  MsgID: Word;
  Addr: Pointer;
  M: THandlerProc;
begin
  MsgID := TDispatchMessage(Message).MsgID;
  if (MsgID <> 0) and (MsgID < $C000) then
  begin
    Addr := GetDynaMethod(PPointer(Self)^, MsgID);
    if Addr <> nil then
    begin
      TMethod(M).Data := Self;
      TMethod(M).Code := Addr;
      M(Message);
    end
    else
      Self.DefaultHandler(Message);
  end
  else
    Self.DefaultHandler(Message);
end;

Im Prinzip holt er sich mit GetDynaMethod nur per RTTI(?) die Adresse der Funktion, welche mit einem MESSAGE Keyword und der entsprechenden MessageId getaggt ist und ruft diese dann im Kontext der aktuellen Instanz auf.

Warum die Nachricht nicht größer als $C000 sein darf, verstehe ich allerdings nicht.

[sirius]

Na zu dynamischen (und auch virtuellen) Methoden in Delphi habe ich hier mal was geschrieben:
http://forum.delphi-treff.de/index.p...mic#post231727

Eine Message-Methode ist ja nix weiteres als eine Dynamische Methode, bei der wir die Nummer vorgeben (= die Zahl hinter dem Wort "message"). Und getDynamethod macht nix weiter als die Methodentabelle nach der entsprechenden message-ID (= Nummer der dynamischen Methode) zu durchforsten. Dazu muss man ggf. auch rekursiv durch die Elternklassen laufen (gilt zwar nicht für das Problem in diesem Thread, aber davon weiß GetDynaMethod ja nix).

Und ein Aufruf einer Methode mit einer anderen Parameterliste ist erstmal kein Problem. Die Maschinensprache kennt sowieso keine Parameter. Die werden per Konvention (stdcall, register, pascal, ...) vorher irgendwo hingelegt. Und bei TMessage sind das ja 4 Zahlen die dann einfach auf dem Stack liegen. Die kann dann die aufgerufene Methode frei interpretieren. Das der Compiler da meckert, wenn die Parameterliste nicht übereinstimmt, ist was Delphieigenes (und auch in den meisten anderen Sprachen). Müsste aber nicht sein. Könnte man auch dem Programmierer überlassen, dass er aufpasst was er macht.

[Zacherl]

Zitat von sirius:

Na zu dynamischen (und auch virtuellen) Methoden in Delphi habe ich hier mal was geschrieben:
http://forum.delphi-treff.de/index.p...mic#post231727

Danke dir