Windows Subclassing
« | 19 Dec 2018 | »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.