Hi,
ich hoffe, der Thomas Woelfer meldet sich hier noch.
Er kennt sich mit der Thematik besser aus als ich
und kann es auch didaktisch besser erklären ;-)
Hier nur ein paar grundsätzliche Anmerkungen zu Windows Events:
Windows Events (Ereignisse) sollten nicht mit
Interrupts (Unterbrechungen) verwechselt werden,
auch wenn manche Events durch Interrupts ausgelöst werden.
Grundsätzlich läuft unter Windows eine Haupt Eventschleife,
die entweder auf Ereignisse lauscht (Polling) oder durch
Interrupts über Nachrichten informiert wird.
Die Ereignisse können aus vielen Richtungen kommen.
Hardware über Hardware Interrupts.
Software über Software Interrups oder sofort als Ereignis.
Falls diese Nachrichten für ein Fenster bestimmt sind, werden
sie durch die Eventschleife an den mit diesem Fenster verbundenen
Prozess weitergeleitet.
Dabei wird ein manchmal langer Routing Weg über diverse
Softwareebenen beschritten.
Darauf möchte ich hier aber nicht näher eingehen, da dies zu
sehr verwirren könnte.
Die Anwendung kann diese Nachrichten entweder ignorieren oder
z. B. über sogenannte Message Maps mit den Event Handler Routinen
(Callbacks) verbinden.
Die Anwendung sollte der Event Schleife abschließend mitteilen,
ob das Event erledigt/verbraucht ist oder es noch an
andere Interessenten weitergeleitet werden soll.
Außerdem kann auch eine Anwendung Events erzeugen und verschicken.
Zur Info:
Es gibt Alternativen zum oben beschriebenen Windows Konzept.
Da melden sich z. B. die Programme bei der Event Schleife an
und teilen dieser mit, an welchen Events sie interessiert sind
und mit welchem Callback sie darauf reagieren.
Die Event Schleife leitet dann nur noch die angemeldeten Events
weiter, was die Nachrichten Traffic und damit die CPU Belastung
deutlich minimieren kann.
Dieses Konzept findet man z. B. in ähnlicher Form unter Java
oder unter SUN OpenView in Verbindung mit XView.
Falls ich irgend etwas falsch beschrieben habe,
möge man mich bitte darauf hinweisen und mir ansonsten gnädig verzeihen....