Windows Subclassing

Subclassing ist meiner Meinung nach einer der dümmsten Begriffe, die in der Windows Welt beheimatet sind. Ursprünglich dachte ich, dass sich den Begriff ein Anfänger einfallen gelassen hat und das Internet den Begriff verbreitet hat.

Doch offenbar stammt der Begriff von Microsoft höchst selbst und ist somit zulässig.

Jedes Fenster (Hauptfenster, Buttons, Textfelder, …) hat eine Fensterklasse und eine damit verknüpfte Ereignis-Funktion. Das Betriebssystem sendet Nachrichten an ein Fenster, in dem eben diese Ereignis-Funktion mit entsprechenden Parametern aufgerufen wird.

Als Programmierer kann man dieses Ereignis abfangen, mitlesen und auch verändern, wenn man die Ereignis-Funktion des Fensters durch seine eigene ersetzt.
… und das heißt dann subclass a window.

Dass für Fenster der Begriff “Klasse” benutzt wird, ist … naja … nicht ganz mein Fall, wobei mir auf die Schnelle auch nichts besseres einfällt. Und dass man mit dem Umleiten eines Funktionspointers eine “Unterklasse” erstellt, gefällt mir noch weniger.

Wie auch immer, die technische Notwendigkeit dieser Umleitung ist gerade bei objektorientierten Sprachen wie C++ sehr hilfreich. Denn hier wollen wir in der Regel von flachen C Funktionen den Codefluss in C++ Objektmethoden umleiten.

Im Konzept der Windows API senden Fenster vom Benutzer ausgelösten Ereignisse in der Regel an ihr Elternfenster, und dort nimmt die vom Programmierer hinterlegte Ereignis- Funktion alles entgegen und behandelt es (z.B.: click oder resize).

Es gibt aber auch interne Ereignisse, die an das Ursprungsfenster gesendet werden, vor allem wenn es um Grafik und das Neuzeichnen von Fensterinhalten geht.
Gerade hier ist es oft hilfreich, manche Ereignisse der BUTTON-Klasse oder der TREEVIEW-Klasse abzufangen, zu verhindern oder zu verändern.
Und eben genau dafür ist subclassing gut.

Im GATE Projekt wird tatsächlich jedes Fenster ge-subclass-t, auch die Hauptfenster, wo man meinen könnte, sie haben ohnehin eine vom Framework bereitgestellte Fensterprozedur.
Doch Fehlanzeige, die durch GATE selbst erzeugten Fensterklassen verweisen auf DefWindowProc, sie behandeln selbst gar nichts und müssen daher gesubclasst werden, um zu funktionieren bzw. um auf etwas zu reagieren.

Nachdem somit jedes Fenster, egal ob vom Betriebssystem gesponsort oder selbst fabriziert, gesubclasst wird, schafft das GATE Framework somit eine Gleichberechtigung zwischen allen Fenstern.

Zugegeben, Geschwindigkeitswettrennen gewinnt man damit nicht, doch das ist auch nicht die Zielsetzung.

Nachdem Windows seine Nachrichten recht unterschiedlich verteilt (einmal zum Elternfenster, einmal zum Eigentümer), hilft diese Strategie Ereignisse besser zu katalysieren.

Wie in fast allen OO Sprachen werden somit am Ende der Kette alle Ereignisse beim zuständigen Objekt des Fensters bearbeitet und nicht bei den Eltern.

Es ist aber lustig, wenn man sich ansieht, wie dieses Konzept dann in fast allen Frameworks wieder ad-absurdum geführt wird. Denn auch in dotNet und Java landen Ereignisse beim Ursprünglichen Objekt, werden aber dort durch Delegates und anonyme Funktionen oft wieder auf eine Funktion im Elternfenster (zumeist das Hauptfenster) umgeleitet um dort zentral behandelt zu werden.

… also gewinnt man auch hier keinen Speed-Contest.