Zitat von
negaH:
@jbg
Zitat:
Bei PeekMessage stimme ich dir zu, aber GetMessage betreibt kein Polling
Tja ich weiß nicht so recht. Woher hast du diese Informationen ??
Debugging.
GetMessage ruft die gleiche interne Funktion auf, die auch WaitMessage aufruft. Und zu WaitMessage sagt das
PSDK
Zitat:
The WaitMessage function yields control to other threads when a thread has no other messages in its message queue. The WaitMessage function suspends the thread and does not return until a new message is placed in the thread's message queue.
Sieht mir doch stark nach "nicht polling" aus.
Zitat:
PeekMessage() in einer Loop würde also die meiste Zeit dieses Flag pollen, sofort zurückkehren und dann wiederum sofort Pollen.
Das merkt man an der CPU Belastung. (Zusatzinfo: Application.ProcessMessages ruft auch nur PeekMessage in einer Schleife auf)
Zitat:
Der günstigste Fall nimmt an das GetMessage() so wie oben arbeitet. Also Ereignissorientiert, schön.
Es sieht danach aus und "fühlt" sich auch so an.
Zitat:
Der ungünstige Fall nimmt an das GetMessage() mehr erledigen muß als nur Messages zu holen.
Ja. Es macht mehr und zwar vor dem internen WaitMessage und danach. Was es da nun genau macht, habe ich mir nicht angeschaut. Es dürfte aber mit den Parametern und dem Auslesen der Message-Queue zu tun haben.
Zitat:
Das GetMessage() noch aus Win2.0 bekannt ist und demzufolge Kompatibilitätsrestriktionen unterworfen ist.
Zugegeben, damals gab es noch keine Threads, aber es wurde trotzdem Rechenzeit an andere Anwendungen abgegeben. Nach außen hat sich nichts geändert. Die Messageloop sieht auch immer noch so aus, wie sie zu Win 3.1 Zeiten war.
Zitat:
Das GetMessage() als Highlevel Funktion auf LowerLevel
API zurückgreift und einfach in einer Loop per PeekMessage() pollt.
Das macht sie auf keinen Fall. Das ist eher das, was Application.ProcessMessages macht.
Zitat:
Es steht also 3 zu 1 das GetMessage() pollen KÖNNTE.
Habe ich das jetzt mit obigen Argumenten wiederlegt?