Ниже приведен классический цикл сообщений. В TranslateMessage(const MSG*), как говорит MSDN, переводят сообщение виртуального ключа (WM_KEYDOWN) в сообщение символа (WM_CHAR). Затем он опубликует это только что переведенное сообщение WM_CHAR в очередь сообщений потока.Понимание заказа символьного сообщения, отправленного с TranslateMessage()
AFAIK очередь сообщений должна быть FIFO структура, и сообщение WM_CHAR будет отправлен в конце очереди, когда TranslateMessage возвращается. Я делаю эксперимент, который одновременно нажимает несколько клавиш, например, 'a', 's' и 'd'. И я положил sleep(1000), чтобы эти сообщения 3 WM_KEYDOWN были помещены в очередь в очереди сообщений перед вызовом TranslateMessage().
while (GetMessage(&msg, NULL, 0, 0))
{
Sleep(1000) // make message queue receives all the WM_KEYDOWN before Translated
TranslateMessage(&msg);
DispatchMessage(&msg);
}
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
print_the_message(uMsg, wParam);
}
Я ожидаю, что заказ должен быть
- WM_KEYDOWN ('а')
- WM_KEYDOWN ('s')
- WM_KEYDOWN ('е')
- /* Queued перед тем спать сна */
- WM_CHAR ('a')
- WM_CHAR ('s')
- WM_CHAR ('е')
Но print_the_message на самом деле показывает, что это заказ
- WM_KEYDOWN ('а')
- WM_CHAR ('а')
- WM_KEYDOWN ('s')
- WM_CHAR ('s')
- WM_KEYDOWN ('е')
- WM_CHAR ('е')
ли символ сообщение WM_CHAR созданного TranslateMessage имеет особый приоритет или обработки, чтобы сделать это может следовать за предыдущее WM_KEYDOWN сообщением и сократить в очереди?
Термин «очередь» в очереди сообщений - это только абстракция, полезная для умственного моделирования ее поведения. Это не соответствует поведению в очереди FIFO, что хорошо на практике. Как вы узнали. Довольно важно, чтобы он работал таким образом, конечно, представьте, что произойдет, если сообщения WM_KEYDOWN предназначены для клавиши Shift или Control. –