What you have put is documented in the help, dont dispute that, but the problem I’m experiencing is the delay in the events being processed can cause problems, namely a FIFO becomes LIFO, when dealing with mouse events. There is no mention of this in the documents.
With a keyboard there can only ever be two events, keypress down and keypress up, but with a mouse there can be just a single mouse down event and single separate a mouse up event and no paired mouse down and mouse up events, because the user can press and hold down a mouse button on the systray icon and then move the mouse point off and away from the systray icon.
Likewise a user can press and hold down a mouse button on an empty part of the desktop or taskbar and whilst still holding down the button can move the mouse pointer over the systray icon before releasing the mouse button, generating a mouse up event.
Like I said previously, you cant do those actions with a keyboard because the keys cant be moved and so dont generate a position.
So using post and sending the event to the back of the queue seems to be the only way to process these mouse events in the correct order.
I disagree with that, because the order of events is in itself important meta data, that can be used to highlight outside interference.
So I’ve written an app in the past, which posted events to another app to interfere with it for testing purposes, it could as you would put it, generate events in any order but this is why its important events are received and processed in order.
Those Win32 API’s I posted above are now subject UIPI constraints.
[User Interface Privilege Isolation - Wikipedia]
(User Interface Privilege Isolation - Wikipedia)
because posting events and other messages can be used to create one of these attacks.
Shatter attack - Wikipedia
However there is still a way to mess around with other programs so events are not processed in the right order and that can still cause problems.