This is somewhat of a general question regarding Windows programming:
Are Window messages "reliable"?
For example (these are just examples):
Can you be certain that a WM_MOUSEMOVE will happen before a cursor enters your screen?
Can you be certain that you will get a WM_DEVICECHANGE message if a device is inserted?
Can you be certain that you will receive a WM_KILLFOCUS message if your window loses focus?
Or, in other words: Can you be certain that you'll get the appropriate message at the appropriate times, or do you always have to code defensively in case that, somehow, you might miss a message for no apparently documented reason?
Example:
It is guaranteed (AFAIK) that a file system filter driver will not "miss" a file operation or change notification.
By contrast, it is not guaranteed that ReadDirectoryChangesW will not miss a notification. In fact, it can miss quite a few if its buffer overflows.
Note:
I am not talking about a situation against an adversary (e.g. someone hijacking your window procedure or installing a hook/filter); that would pretty much invalidate any guarantee. I'm only asking about obscure situations that could really happen even if no one meant anything bad intentionally, like if some random buffer overflows, if someone uses SendInput, etc., assuming you have control of your own code.
No you cannot be certain that a given message will be delivered in a specific order. Here are a couple of reasons why not
Messages can be sent progamatically and this can be used to simulate "impossible" scenarios like a WM_KEYUP followed by a WM_KEYDOWN.
Another routine could sub-class your window and selectively intercept messages and not send them on to your WNDPROC
It's best to code defensively around any scenarios where ordering is important
Related
This is a continuation from What is the correct, modern way to handle arbitrary text input in a custom control on Windows? WM_CHAR? IMM? TSF?.
So after experimenting with a non-IME layout (US English), a non-TSF IME (the Japanese FAKEIME from the Windows XP DDK), and a TSF text service (anything that comes with Windows 7), it appears that if the active input processor profile is not a TSF text service (that is, it is a TF_PROFILETYPE_KEYBOARDLAYOUT), I'll still have to handle keystrokes and WM_CHAR messages to do text input.
My problem is that my architecture needs a way to be told that it can ignore the current key message because it was translated into a text input message. It does not care whether this happens before or after the translation; it just needs to know that such a translation will or has happened. Or in pseudocode terms:
// if I can suppress WM_CHAR generation and synthesize it myself (including if the translation is just dead keys)
case WM_KEYDOWN:
case WM_SYSKEYDOWN:
if (WillTranslateMessage())
InsertChar(GenerateEquivalentChar());
else
HandleRawKeyEvent();
break;
// if I can know if a WM_CHAR was generated (or will be generated; for instance, in the case of dead keys)
case WM_KEYDOWN:
case WM_SYSKEYDOWN:
if (!DidTranslateMessage())
HandleRawKeyEvent();
break;
case WM_CHAR:
case WM_SYSCHAR:
InsertChar(wParam);
break;
The standard way of handling text input, either from a keyboard or through a non-TSF IME, is to let TranslateMessage() do the WM_KEYDOWN-to-WM_CHAR translation. However, there's a problem: MSDN says
If the message is WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, or WM_SYSKEYUP, the return value is nonzero, regardless of the translation.
which means that I cannot use it to determine if a translation has occurred.
After reading some Michael Kaplan blog posts, I figured I could use ToUnicode() or ToUnicodeEx() to do the conversion myself, passing in the state array from GetKeyboardState(). The wine source code seems to agree, but it has two special cases that I'm not sure if they are wine-specific or need to be done on real Windows as well:
VK_PACKET — generates a WM_CHAR directly out of the message's LPARAM
VK_PROCESS — calls a function ImmTranslateMessage(), which seems to either be a wine-specific function or an undocumented imm32.dll function; I can't tell which is true
And wine also does nothing with WM_KEYUP and WM_SYSKEYUP; again, I don't know if this is true for wine only.
But do I even need to worry about these cases in a program that uses TSF? And if I do, what's the "official" way to do so? And even then, what would I do on WM_KEYUP/WM_SYSKEYUP; do I need to send those to ToUnicode() too? Do I even need to catch WM_KEYUPs in my windows specially if there was a WM_CHAR?
Or am I missing something that is not in any of the MSDN TSF samples that will allow me to just have TSF take care of the TF_PROFILETYPE_KEYBOARDLAYOUT processors? I thought TSF did transparent IME passthrough, but my experiment with the FAKEIME sample showed otherwise...? I see both Firefox and Chromium also check for TF_PROFILETYPE_KEYBOARDLAYOUT and even use ImmGetIMEFileName() to see if the keyboard layout is backed by an IME or not, but I don't know if they actually take care of input themselves in these cases...
My minimum version right now is Windows 7.
Thanks.
UPDATE The original version of this question included needing to know about associated WM_KEYUPs; on second look through my equivalent code on other platforms this won't be necessary after all, except for the details of TranslateMessage(); I've adjusted the question accordingly. (On OS X you don't even give key-release events to the text input system; on GTK+ you do but it seems keypresses that insert characters don't bother with releases and so they don't get handled anyway, at least for the input methods I've tried (there could be some that do...).) That being said, if I missed something, I added another sub-question.
In general, it's not a good idea to try to duplicate Windows internals. It's tedious, error-prone, and likely to change without notice.
The edit controls that I have source access to pick off arrow keys (and other specific keys) in the WM_KEYDOWN handler and pass everything else off to the default handler, which will (eventually) generate WM_CHAR or TSF input calls (if your control supports TSF, which it should).
You would still need WM_CHAR in the case where there is no TSF handler involved. However, you can always have your WM_CHAR handler call your ITextStoreACP::InsertTextAtSelection method.
I've done some research (with single input device altrough) in this field and discovered that in most situations messages are sent by pair, first WM_INPUT and then WM_KEYDOWN. So it's merely possible to link them together for filtering, i.e. WM_INPUT flags that it's corresponding WM_KEYDOWN shoudn't be sent to reciever (in my case first i discard all WM_KEYDOWN and then decide whenever i need to send them back to their recipients). I just assume that all next WM_KEYDOWN are belong to last WM_INPUT.
My question exactly: can i seriously rely on that principle? Won't those messages mix up if i use multiple input devices?
There are some serious questions about its reliability already:
1. How do i distinguish repeating input from multiple devices (answer is obvious - i can't).
2. Would WM_INPUT-WM_KEYDOWN pairs mix up in case of input from multiple devices? i.e. form an cortege like WM_INPUT, WM_INPUT, WM_KEYDOWN, WM_KEYDOWN?
Also maybe it is possible to just discard all WM_KEYDOWN and generate all keyboard events by myself? Altrough it would be technically quite difficult, because there may be multiple WM_KEYDOWNs from one WM_INPUT (key repeatence work that way, multiple WM_KEYDOWN, one WM_KEYUP).
Just in case, here's what i need to achieve:
I need to filter all messages by time between them. All user input gets filtered by time interval between keypresses. If two messages were sent with interval <50ms i discard first message and second awaits while its TTL exceeds and if so, it sent to its recipient.
Difficulty is that there can be multiple input devices and those timings will mess up with each other.
I understand your issue having multiple devices and things getting messed up.
Every device has there Product and Vendor Id which is not same, so what I suggest is to is to differentiate them on the basis of their Product and Vendor Id.
I have been working on a HID device recently so this might help you too.
I figured out that keyboard hook (WH_KEYBOARD) actually occurs before WM_KEYDOWN message, can't check if simultanious input from several devices will mess up order of WM_INPUTS and KeyboardHook events (like sequence of events: Dev0_WM_INPUT Dev1_WM_INPUT Dev0_KBDHook Dev1_KBDHook - altrough that sequence of event will be handle, what i fear is if Dev1_KBDhook will appear before Dev0_KBDhook or worse).
With WM_KEYDOWN such mess was possible, still don't know if it will be same with keyboad hook.
Anyway it is possible solution. On WM_INPUT i create Message itself and partly fill, on next KeyboardHookEvent i just fill remaining part.
Generally WM_INPUTs and KeyboardHook events occur by pairs, but as i mentioned before, i don't exactly know if it can mess up, but if even so, if it will maintain order of KeyboardHookEvents and WM_INPUTS (like Dev0_INPUT, Dev1_INPUT and then Dev0_KBDEvent, Dev1_KBDEvent) it will give no trouble to parse those sequences. For example one stack:
WM_INPUT pushes new message struct, KBDEvent pops and fill remaining parts.
Not generally good solution, but i guess it is good enough to use if no other exists, solves the problem, atleas partially.
If i'll manage to test its behavious upon simultanious input from multiple devices, i will post info here. Altrough i really doubt there will be any mess that can't handled. Unless windows chooses time to send corresponding keyboard event by random...
Forgot to mention, yes it's partially possible to discard all input and generate manually. I just PostMessage manually forged message (i get lparam from KeyboardHookEvent). But it will give some problems. Like hotkeys won't work and also anything that uses GetAsyncKeyState. In my case it is acceptable altrough.
I've got a routine that looks something like this, in pseudocode:
while PeekMessage(Message, 0, 0, 0, PM_REMOVE)
HandleMessageAppropriately(Message)
Basically, it goes through and pulls all messages out of the queue and dispatches them. I can't change this routine.
I've got a scenario in which this routine, if it's being called under certain conditions and there's a message in the queue representing the user having hit ESC at exactly the wrong moment, it can cause the program to crash. (Gotta love race conditions.)
I can't change the routine above, but I can change the code that calls it. Is there any way that I can do something immediately before this is run that will say "go through the message queue and remove all keyboard input messages where the user hit ESC, without affecting the rest of the items in the queue or changing their order"?
You can use the range parameters in PeekMessage to restrict to the WM_CHAR message only, and PM_NOREMOVE to leave the message queue intact if the character isn't ESC; if the message needs to be removed, repeat the process with the PM_REMOVE flag. Unfortunately there's no way to look past the first WM_CHAR in the queue.
This is the exact equivalent to the infamous DoEvents call that got so many VB6 programmers in trouble. Because surely the ESC keypress is closing a window, leaving code running in a loop without a user interface anymore. The outcome is invariably poor.
You don't mess around with this, you call EnableWindow(hWnd, FALSE) before you enter this loop to disable input on the window that shouldn't be closed. Now you don't care anymore what's in the message queue. The exact same thing that dialogs do.
Don't paper over a modal loop. Make it modal, make it obvious to the user too.
You may be best to hook the call to PeekMessages and replace it with a version that does what you need.
You could use madshi's hooking routines but it's not hard - I've published a simple hook routine here on Stack Overflow.
If the code was running in an executable module that you compile then you could compile a customised version of Windows.pas that replaced PeekMessage. Of course I'm guessing that you code is Delphi.
MSDN advises that RegisterWindowMessage() function is only used for registering messages to be sent between the processes. If a message is needed for sending within one process it can be safely selected from the range WM_APP through 0xBFFF.
However in our codebase I often see that RegisterWindowMessage() is used for messages only sent within one process. I suppose that this was done because of perceived simplicity of using RegisterWindowMessage() since it doesn't require manually distributing the message identifiers in the WM_APP..0xBFFF range.
Do I understand correctly that if many applications are run on one machine and they all call RegisterWindowMessage() with different strings they could exhaust the range of message identifiers allowed to return by RegisterWindowMessage() and for some of them it will just return a value indicating a failure? What could be a valid reason for using RegisterWindowMessage() messages in cases where WM_APP..0xBFFF range messages would suffice?
IMHO there is no valid reason to use RegisterWindowMessage if you are only sending messages to yourself
There is no (documented) way to un-register a message, so after your app quits, that registered message will stay in the atom table until reboot/logoff (I can't remember exactly where this atom table is stored, the window station or terminal server session instance probably)
The reason you need to use RegisterWindowMessage even when messaging to yourself is that it protects you from the idiot who broadcasts messages in the WM_APP + N range.
Yes, this does happen.
Abusing RegisterWindowMessage can potentially make a windows box unusuable. This is especially true if the window message names are dynamically generated and a bug causes out of control windows message allocation. In this case the global atom table in your windows station/ desktop will fill up and any process using User32.dll (basically, any app) will fail to start, create windows, etc.
There is a bug out there in Delphi / Borland products that registers messages that start with ControlOfsXXXXXX where XXXX is a memory address (or other dynamic modifier). Apps that are started and stopped frequently will register multiple ControlOfsXXXX atoms and eventually exhaust atom space. For more details see:
http://blogs.msdn.com/b/ntdebugging/archive/2012/01/31/identifying-global-atom-table-leaks.aspx
And
https://forums.embarcadero.com/thread.jspa?threadID=47678
A possible advantage is that Spy++ can display more informative text, therefore debugging is a bit easier. Compare
<00058> 00330CA2 S message:0x0419 [User-defined:WM_USER+25] wParam:00000000 lParam:00000000
with
<00129> 004F0DA0 S message:0xC2B0 [Registered:"AFX_WM_ONCHANGE_ACTIVE_TAB"] wParam:00000001 lParam:02B596E8
Of course, in principle there is a chance to run out of message IDs. On the other hand, in the source code of the MFC Feature Pack there are 52 calls to RegisterWindowMessage. So there are still 16300 IDs left for other applications.
This may be the simplest win32 program ever ..
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR cmdLine, int show)
{
MessageBox(0, "Hello world..", "Salutations!", MB_OK);
return 0;
}
.. which makes no calls whatsoever to the usual GetMessage() call. My question is this: if my program doesn't process any window messages, can the OS cope with that? I.e., does it cause memory leaks? Or some other resource that wouldn't be apparent unless I ran it 16K times?
In a broader sense, exactly how 'dependent' is Win32 on applications taking care of their messages? I would hope that when the compiler links the executable as a windows program, that the run-time would be capable of cleaning up any kind of message queue, be it emptied or not.
Just a technicality, but you do have a window, and you do have a message loop, just not in your code.
The call to MessageBox() creates a window (of class #32770) and runs a local message loop, not returning to your code till the message loop drops out, presumably when WM_NCDESTROY is sent. I think it's the same message loop that runs in response to DialogBox().
But you could substitute your call to MessageBox() with anything else that really doesn't create a message loop, and you'll still be fine. Windows doesn't care if you have a message loop, although some functionality (primarily UI related) is difficult or impossible to use without it. In fact, you don't have to link to user32 at all, and some apps that have no user interface don't.
Now if you create a window and don't process messages for it in some way, Windows XP and up will replace your window with a "ghost" window that has a white client area and Task Manager will tell the user that the application is not responding.
Although it seems so at first, the message loop is not magic or a strictly required part of Windows boilerplate. It is highly ingrained as a standard in most Windows applications, though, because it's the best way to handle the dispatching of window messages. The "event-driven" nature of most Windows applications makes us forget sometimes that Windows applications were originally designed to be single-threaded, and in this model, it is code running within that single thread, not some unseen force within the operating system, that must make every function call within our code. The addition of multithreading changed that somewhat, but the basic model still remains the same.
EDIT
A note about message queues:
As is mentioned elsewhere, a message queue is only created (and on a per-thread basis) when a window is created by that thread. Your example program, upon creating a message box, does create a message queue. But this queue need not be empty when your application exits. This queue is just a memory structure. It's a block of memory that can hold a certain number of message objects (specifying destination hWnd, message id, wParam, lParam, system time when message was posted, mouse position when message was posted, and some data that allows the derivation of keyboard and mouse button state when the message was posted), along with pointers to the head and tail of the queue (I assume it's a circular queue). When the application exits, this memory, like all memory belonging to the process, is summarily freed.
There are, of course, other things that must be cleaned up outside your process. The OS must keep a table of all existing windows, for example, along with the thread and process that created them. Of course, these are all cleaned up automatically as well.
Since you don't have a window, you don't need a message loop. In Win32 the messages are sent to windows, not to applications.
You do have a message loop - MessageBox is a modal dialog and therefore contains a message loop within.
You don't have to create windows. But still, there are some kind of messages, like
WM_TIMER
WM_TIMECHANGE
WM_CLIPBOARDUPDATE
WM_COPYDATA
WM_POWER
that you may need. So, a ghost window hanging around wouldn't be bad.
If you don't have a window, then that is fine, but if you do then you need to make sure that you pump messages for it. Otherwise the system can hang on broadcast messages waiting for you to respond. This is important for things like COM which create hidden windows for message processing. If your main thread does not pump messages (e.g., by calling WaitForSingleObject) then calls to your COM objects will not be processed, and any programs which send broadcasts will appear to hang.
I have read somewhere (and can't find the reference) is that Windows will create a message queue on demand. If you never call a function that looks for a message queue, one will never be created. And this occurs on a per-thread basis.