Events - Wann reagiert die Anwendung?
-
Hallo,
Ich habe eine allgemeine Frage zu Events unter Windows. Mein Ziel ist es, zu verhindern, dass mein C++-Programm während einer bestimmten Befehlssequenz unterbricht, um ein Maus-Event zu bearbeiten. Daher meine Frage:
WANN GENAU reagiert meine Anwendung auf ein externes Event?
Ich habe bereits herausgefunden, dass Events nicht etwa asynchron abgearbeitet werden (wie z.B. Interrupts), sondern sequentiell in der Reihenfolge ihres Eintreffens. Aber wann wird denn nun dem Dispatcher (?) die Abarbeitung der Event-Queue gestattet? Wenn mein Programm schläft? ...Oder kann es vlt. doch - wie bei einem klassischen Interrupt - jederzeit passieren?
Z.Zt. versuche ich meine "atomare" Befehlssequenz durch eine Critical Section zu schützen. Jetzt bin ich mir aber nicht mehr so sicher, ob das nicht falsch/unnötig ist (Die Anwendung ist eigentlich Single-Threaded!).
Gruß
-- oXmoX
-
Die schlechte Nachricht: eine CriticalSection bringt dir hier nichts.
Die gute Nachricht: du musst schlicht und ergreifend garnichts machen.
Das was du "Events" nennst sind Window-Messages, und die landen erstmal einfach in einer Queue (Warteschleife).
Irgendwo in deinem Programm gibt es dann eine schöne Schleife ("while"), die Stück für Stück Nachrichten aus der Warteschleife nimmt, und diese "abarbeitet".Wenn du ein GUI Framework ala MFC verwendest, ist diese Schleife irgendwo tief im Framework vergraben, d.h. du siehst sie nicht. Ansonsten musst du sie selbst schreiben. (Dann müsstest/solltest du aber eigentlich wissen wo/wie diese Window-Messages abgearbeitet werden.)
Einfach ausgedrückt kann man sagen: neue Nachrichten werden immer nur dann abgearbeitet, wenn das Programm sonst nichts tut.
Ich habe bereits herausgefunden, dass Events nicht etwa asynchron abgearbeitet werden (wie z.B. Interrupts), sondern sequentiell in der Reihenfolge ihres Eintreffens.
Bis auf wenige Ausnahmen stimmt das. Die Ausnahmen sind WM_PAINT (Fenster neu zeichnen) und WM_TIMER (kommt wenn ein Timer "abgelaufen" ist). Diese Nachrichten werden nicht in die Queue gestellt, sondern immer nur dann generiert, wenn sonst keine anderen Nachrichten in der Queue sind, d.h. die Queue leer ist. Sollte in deinem Fall aber keine Rolle spielen.
-
hustbaer schrieb:
Die Ausnahmen sind WM_PAINT (Fenster neu zeichnen) und WM_TIMER (kommt wenn ein Timer "abgelaufen" ist). Diese Nachrichten werden nicht in die Queue gestellt, sondern immer nur dann generiert, wenn sonst keine anderen Nachrichten in der Queue sind, d.h. die Queue leer ist.
weiß nicht, ob es heute noch so ist. früher wurden, wenn ich mich recht erinnere, auch Mausnachrichten zusammengefaßt und die anwendung hat nur die letzte gesehen oder nur zehn pro sekunde oder so.
kann mich jemand aufklären, wie das heute ist?
-
volkard schrieb:
weiß nicht, ob es heute noch so ist. früher wurden, wenn ich mich recht erinnere, auch Mausnachrichten zusammengefaßt und die anwendung hat nur die letzte gesehen oder nur zehn pro sekunde oder so.
kann mich jemand aufklären, wie das heute ist?http://blogs.msdn.com/oldnewthing/archive/2003/10/01/55108.aspx
-
Vielen Dank! Ich sehe jetzt etwas klarer.
-
audacia schrieb:
http://blogs.msdn.com/oldnewthing/archive/2003/10/01/55108.aspx[/url]
danke. das ist sehr klar und einfach und sinnvoll und überhaupt.
-
audacia schrieb:
volkard schrieb:
weiß nicht, ob es heute noch so ist. früher wurden, wenn ich mich recht erinnere, auch Mausnachrichten zusammengefaßt und die anwendung hat nur die letzte gesehen oder nur zehn pro sekunde oder so.
kann mich jemand aufklären, wie das heute ist?http://blogs.msdn.com/oldnewthing/archive/2003/10/01/55108.aspx
cool, wieder was dazugelernt. danke euch beiden.
