Nein nicht ganz.
Betrachte die Summe aller Komponenten die man hooken möchte als die Arbeit mehrer Programmierer. Man muß also alles das Wissen was eine Gruppe von Programmierern verzapft haben. Wenn man nun selber Komponenten schreibt dann werden das auch nur eine Teilmenge von denen sein die man hooken müsste, ergo: nicht mehr ganz so
paradox 
Aber das wird zu philosophisch.
Die Kernaussage bleibt besteht:
Hooken und solche Tricks bedingen das der Programmierer ein sehr teifgründiges Wissen besitzen muß. Dieses Wissen wird mindestens so tief sein wie das eines erfahrenen Komponentenentwickler. Ist dem nicht so so wird man mit Hooks meistens mehr kaputt machen als reparieren. Die Frage nach mehr zusammengefassten Backgroundwissen ist also korrekt, nur habe ich eben keine Antwort darauf wo man solche fundierten Sachen nachlesen könnte, als im Source selber.
Schau mal, wer kann sich heute als Komponetenentwickler bezeichnen ?
All diejenigen die selber Komponenten schreiben, logisch. Da diese Entwickler die meiste Zeit nur Komponeten auf eine fertige konstruierte Basis aus Komponeten draufsetzten, wie zb. Propertyeditoren für die
IDE usw. usw. heist das auch das ein Komponentenentwickler heutzutage nicht zwangsläufig darüber bescheid wissen muß was er da eigentlich benutzt.
Das ist ja das schöne an der Arbeitsweise der
OOP, bzw. im Grunde exakt ihr Ziel.
Ein Hook greift aber ganz unten, im innersten in das Prozessing einer oder sogar einer ganzen Gruppe von Komponenten ein. Der Hook bekommt auch innere Staties mit die man aussen der Schnittstelle Komponente garnicht ansehen kann. Denoch ist es wiederum so das ein Hook niemals komplett alles über die gehookte Komponete wissen kann, das diese eben private Felder/Staties/Methoden benutzt die nicht über die WindowProc laufen.
Egal: über die Komponeten der
VCL gut bescheid zu wissen kann nie schaden. Borland liefert die Sourcen mit, ergo kann man darin stöbern, und ich habe es auch so gelernt. Nur einen Abriß der fundiert ist wird man meines erachtens so nicht finden, das wäre ein dickes Buch.
Grundsätzlich muß er fast alle Messages berücksichtigen, da sie fast alle das Ziel haben einen internen Status, zb. Text, im
GUI darzustellen/sie zu editieren und auch das darzustellen, und exakt das möchte er verändern. Es gibt nur sehr wenige Windowsbotschaften die redundant sind. Zb. wm_Size,wm_Move,wm_Activate zu wm_WindowPosChanged/wm_WindowPosChanging. Die in der
VCL eingeführten Messages, die nichts mehr mit Windows zu tuen haben, sind die cm_XXXX Messages. Deren Arbeitsweise kann sich leicht zu den Windowsbotschaften unterscheiden und sind in ihrer Menge genauso groß wie die Windows Botschaften. Deren logischer Aufbau ist dabei intuitiver und logischer konstruiert als die Windowsbotschaften. Sehr oft sind es gemappte Windowsbotschaften wie wm_SetFocus zu cm_Activate/cm_Deactivate die eine Nachricht an ein TWinControl benutzen das dann diese Nachricht als cm_XXXX Nachricht broadcastet an seine untergeordneten TControl's, die ja kein eigenes Fensterhandle besitzen.
In vielen Fällen könnten also die cm_XXXX Messages ausreichend sein sie zu hooken und darauf zu reagieren, aber eben nicht immer. Die Deklaration der cm_XXXX Messages findet man in
Unit Controls.pas.
Zb. die wm_Paint Messages zu Hooken ist gefährlich. Macht man dort einen Fehler, zb. die Fragestelleung wann muß man den
DC->Devicecontext der in Message.wParam übergeben wurde, wenn er übergeben wurde, freigeben oder nicht, kann Speicherleaks im
GDI verursachen. Ein Fehler dabei und man hat in Millisekunden oder erst Stunden die
GDI Resourcen bei den
DC's überschritten, für's gesammte System wohlgemerkt. Danach funktioniert garnichts mehr, sogar der Taskmanager wird nicht mehr richtig dargestellt.
Bei Windowscontrols ist es durchaus üblich das diese auf dem Bildschirm zeichnen auch inerhalb anderer Nachrichten. Ganz besonders schlim wurde dies bei den normalen TForm Fenstern, also der Titelzeile eines Windows, gemacht. Klickt man mit der Maus auf den Schließenbutton so wird wm_NCLButtonDown gesendet. Windows beginnt nun eine Schleife die erst zurück kehrt wenn der Button wieder losgelassen wird. Innerhalb dieser Schleife werden die Fensterbuttons und Titelzeile neu gezeichnet, unabhängig von wm_Paint und wm_NCPaint. Ein Hook muß also wm_NCLButtonDown abfangen und dann ALLES selber machen. Nun ist es aber so das sich gerade der Code dieser Schleife, auf den wir keinen Einfluß haben, mit jeder neuen Windowsversion ständig veränderte und es kein
API zur Beeinflussung dafür gibt.
Das zeigt uns das
1.) es schon eine Kunst ist einen 4'ten Button in der Titelzeile einzublenden
2.) warum so viele Tools die so einen Button einblenden fast nie ganz sauber arbeiten, besonders bei neuen Windows Versionen versagen sie.
Diese Problematik ist ein Beispiel für die Anwendung von Hooks, deren Komplexität und eben auch der "Gefahren" dabei. Ist natürlich ein extremes Beispiel.
Gruß Hagen