2016-07-18 9 views
0

Ich schreibe eine Protokollierungsfunktion, die Socket-Ereignisse registriert. Das Problem, das ich habe, ist, dass, obwohl ich die time der Veranstaltung in der MSG Struktur habe, die ich bekomme, wenn ich PeekMessage nennen, der nachfolgende Aufruf DispatchMessage wird am Ende von WindowProc umgegangen wird, die nicht die time als erhält Parameter.Die richtige Art, die Zeit in MSG zu verwenden

Die "Lösung", die ich verwende, um Zeiten zu protokollieren, besteht darin, Socket-Ereignisse in der Hauptschleife meiner Windows-Anwendung zu erkennen, wo PeekMessage auftritt.

Was wäre der richtige Weg, dies zu tun? Ich würde es eher bevorzugen, keine logging-spezifische Logik zu einer ansonsten allgemeinen Routine hinzufügen zu müssen.

Antwort

2

Verwenden GetMessageTime() in Ihrer Steckdose Nachrichtenhandler:

Ruft die Nachricht Zeit für die letzte von der GetMessage() Funktion abgerufenen Nachricht. Die Zeit ist eine lange Ganzzahl, die die verstrichene Zeit in Millisekunden vom Zeitpunkt des Systemstarts bis zur Erstellung der Nachricht (dh in der Nachrichtenwarteschlange des Threads) angibt.

Im Vergleich zum time Feld der MSG Struktur:

Der Zeitpunkt, an dem die Nachricht veröffentlicht wurde.

+0

Weiterführende Literatur: https://blogs.msdn.microsoft.com/oldnewthing/20090618-00/?p=17843 – theB

+0

Danke Remy. Ich sehe jedoch immer noch nicht, wie ich dadurch die spezifische Logik außerhalb der Hauptschleife bewegen könnte, weil das bedeutet, GetMessage an einem Ort und GetMessageTime an einem anderen Ort aufzurufen (wo die spezifische Logik sitzt). Dann gäbe es keine Garantie für die Übereinstimmung zwischen dem Ereignis und seiner Zeit. –

+0

Ihre ursprüngliche Lösung bestand darin, 'PeekMessage' in der Hauptschleife aufzurufen und den Zeitstempel von der' MSG'-Struktur zu erhalten. 'GetMessageTime' gibt den gleichen Zeitstempel zurück. Was ist das Problem, das Sie beim Aufruf von 'GetMessageTime' in Ihrem 'WindowProc'-Handler haben? –