A customer was adding diagnostics to their application and wanted to know if there was a way to detect that the application was being slow in processing its input. These sorts of delays manifest themselves to the end user as a sluggish application which is slow to respond to input events. They already had a watchdog timer that was reset every time their Get­Message call returned a message, so they could capture stack traces if their application stopped processing messages for more than X milliseconds. They wanted to extend this diagnostic information to input delays. Fortunately, there’s an easy way to tell. The Get­Message­Time will tell you the time the message was added to the queue, so by subtracting that time from the current Get­Tick­Count, you can determine how long the input message sat in the queue. (Sent messages are not queued messages, so calling Get­Message­Time for a sent message doesn’t work.) There’s a catch, here, though.

Since mouse messages are generated on demand, the Get­Message­Time for a WM_MOUSE­MOVE message is usually “Just now.” (It could be older if you forced a mouse move message to be generated but left it in the queue.) To get the actual time the mouse moved, you need to use Get­Mouse­Move­Points­Ex.