Kann ich Windows-Messagehandler einer Form auslagern?

[Der schöne Günther]

Auf die Schnelle auf spezielle Windows-Messages an mein Formular reagieren zu können geht fantastisch einfach:

Delphi-Quellcode:

unit Unit10;

interface

uses
   System.Classes,
   Winapi.Windows, Winapi.Messages,
   Vcl.Controls, Vcl.Forms;

type
   TForm10 = class(TForm)
      protected
         procedure WmSize(var Message: TWMSize); message WM_SIZE;
   end;

var
   Form10: TForm10;

implementation

{$R *.dfm}

procedure TForm10.WmSize(var Message: TWMSize);
begin
   if Message.SizeType = SIZE_MAXIMIZED then
      self.Color := Random($00FFFFFF);

   inherited;
end;

end.

Möchte man aber auf ein halbes oder ganzes Dutzend verschiedene Messages reagieren, bläht das die Klassendefinition des Formulars ziemlich auf. Wie könnte ich das ganze an eine separate Klasse deligieren? Als erstes dachte ich, mich einfach in

Delphi-Quellcode:

TForm.WndProc(..)

einklinken zu können, aber ich stehe auf dem Schlauch, wie ich die dort ankommenden

Delphi-Quellcode:

TMessage

-Records nun bsp. in einen

Delphi-Quellcode:

TWMMoving

-Record umgecastet kriege.

Ich finde die Stelle nicht, wo Delphi das beispielsweise selbst macht. Kann mich jemand hinführen?

[himitsu]

Delphi-Quellcode:

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

oder

Delphi-Quellcode:

Application.OnMessage

für ALLES

[sirius]

Hallo Günther,

Delphi tut da nichts am Record wandeln. Der Compiler überprüft bei einer message Methode nur ob die Struktur so in etwa passt. Der Rest wird über asm-Code erledigt. Daran kommst du über die Methode Dispatch, welche dir von TObject bereitgestellt wird. Du musst also in der WndProc den TMessage Record nur nehmen und Dispatch von deiner Zielklasse aufrufen.

Delphi-Quellcode:

procedure TForm10.WndProc(var Message: TMessage);
begin
  FmyClass.Dispatch(message); //wobei Dispatch sicher nicht public ist, aber das kriegste bestimmt hin
end;

[Der schöne Günther]

Puh, das verstehe ich nicht. Ich möchte noch nicht einmal Messages an die WndProcs von anderen "Fenstern" bzw. fensterbasierten Komponenten auf meiner Form weiterreichen.

Konkretes Beispiel: Ich möchte aus

Delphi-Quellcode:

TMyForm = class(TForm)

   procedure WMEnterSizeMove(var Message:TWMSize); message WM_ENTERSIZEMOVE;
   procedure WMExitSizeMove(var Message:TWMSize); message WM_EXITSIZEMOVE;
   // Und noch viele mehr

end;

lieber ein

Delphi-Quellcode:

TMyForm = class(TForm)
   private var
      meinSpeziellerMessageBehandler: TWindowsMessageHandler;
      
   [...]
end;

TWindowsMessageHandler = class
   private
      procedure WMEnterSizeMove(var Message:TWMSize);
      procedure WMExitSizeMove(var Message:TWMSize);
      [...]         
   public
      procedure handleMessage(var Message: TMessage);
end;

machen.

[sirius]

Delphi-Quellcode:

TWindowsMessageHandler = class
    private
       procedure WMEnterSizeMove(var Message:TWMSize); message WM_ENTERSIZEMOVE;
       procedure WMExitSizeMove(var Message:TWMSize); message WM_EXITSIZEMOVE;
       [...]         
    public
       procedure handleMessage(var Message: TMessage);
end; 


procedure TWindowsMessageHandler.handleMessage(var Message: TMessage);
begin
  dispatch(message);
end;

sollte tun

[TiGü]

Vor dem Problem stehe ich auch, habe aber das immer vor mir hergeschoben mein 10000 Zeilen Hauptformular dahingehend zu entschlacken.

Ich nehme an, dein spezieller Messagebehandler liegt (soll liegen) in einer eigenen Unit.
Wenn wir bei deinen Beispiel aus dem Eröffnungspost bleiben, wie würdest du die Farbe des betreffenden Formulars ändern (oder andere Member des Formulars ansprechen), wenn du zirkulare Referenzen vermeiden willst.
Stehe da gerade im vorweihnachtlichen und nachmittäglichen Gedankenlabyrinth.

[sirius]

Zitat:

Zitat von TiGü (Beitrag 1240258)

wie würdest du die Farbe des betreffenden Formulars ändern (oder andere Member des Formulars ansprechen), wenn du zirkulare Referenzen vermeiden willst.

Normalerweise über eine (abstrakte) Klasse, die eine Elternklasse von TmyForm ist. Nun ist das aber meist mit dem RAD von Delphi nicht vereinbar, also musst du zirkulare Referenzen nehmen oder dir reichen die Properties von TForm aus.

[Aphton]

Wie berits himitsu schrieb

Zitat:

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

Delphi-Quellcode:

TObject.Dispatch(var Message)

zwar nicht im Geringsten (so viel Assembler), aber es funktioniert traumhaft! :thumb:

Ein Problem mit zirkulären Referenzen sehe ich in meiner kurzen Umsetzung nicht: Der Messagehandler muss doch nur in seniem

Delphi-Quellcode:

implementation

-Teilum die konkrete Klasse des Formulars wissen um beispielsweise eine Farbe oder einen speziellen Button darauf anzufassen.

[sirius]

Zitat:

Zitat von Der schöne Günther (Beitrag 1240270)

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:

Zitat von Der schöne Günther (Beitrag 1240270)

Ich verstehe die Implementation von

Delphi-Quellcode:

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:

Zitat von sirius (Beitrag 1240275)

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 :thumb: