A customer had a program that supported the mouse wheel,
and they found that some laptops have
trackpad enhancement software
which supports a gesture for turning the mouse wheel.
When the enhancement software recognizes the gesture,
it sends a WM_ message
to the foreground window..
This causes problems for the program because there are
various things that are not allowed when processing an
inbound sent message.
Fortunately,
they can detect whether they are in this situation,
but it's not clear how they can recover from it.
"We have been brainstorming and thinking that if we see this problem,
we will use PostMessage to put
the message 'back' into our queue."
The trackpad software is supposed to be using
SendInput
so that the wheel message orders correctly with the other messages in your input queue.
The SendMessage delivers the message immediately (or as immediately
as possible),
and
messages posted with the PostMessage function
are processed ahead of input,
both of which are wrong when you are trying to simulate input.
Even your attempt to delay processing by calling
PostMessage won't help because posted messages are processed ahead of input.
Here's a diagram which is inaccurate but may help to get the point across:
| Inbound sent messages | |
← SendMessage inserts messages here |
|
| Inbound posted messages | |
← PostMessage inserts messages here |
|
| Inbound input messages | |
← SendInput inserts messages here |
|
Basically, the enhancement software already screwed you with respect to message ordering. You won't be able to make a perfect recovery; all you can do is try to make the best of a bad situation.
One idea is to use the ReplyMessage function
in your message handler.
The
ReplyMessage function says,
"Hey, like, act like I returned from this message
for the purpose of inter-thread SendMessage
bookkeeping, such as unblocking the sender,
but let me keep running anyway."
This may be enough to get the parts of the system that normally
say "No, you can't do that from inside a sent message" to realize
"Oh, wait, the synchronous part is over. Carry on."
If that doesn't work, then you can use the
SendInput message to generate a wheel message back
into the input queue.
The wheel input will be a bit late (by the amount of time it took your
window procedure to receive the message),
but it'll probably be close enough to correct that most people
won't notice.
There's most likely already a lag in the gesture recognition
in the enhancement software,
so a little more lag probably isn't the end of the world.