- Fix Japanese keyboard about [Shift]+[0] and [半/全] (VK_PROCESSKEY).
- Add user32!CliSaveImeHotKey helper function.
- Implement user32!CliImmSetHotKey function. This function is forwarded from imm32!ImmSetHotKey.
- Fix user32!TranslateMessage by using imm32!ImmTranslateMessage.
CORE-11700, CORE-18183, CORE-18182
GTK applications call GetQueueStatus(QS_ALLINPUT), where QS_ALLINPUT
specifies the QS_RAWINPUT flag as well, when these are compiled for
Windows XP+, and they expect the call to succeed on this platform.
On one side, ReactOS does not currently support this flag at all, but
since it claims to be XP/2003-compatible, applications may implicitly
expect the flag to be supported by GetQueueStatus() and the function
*NOT* failing when this flag is set.
(Later GTK apps don't care and just call GetQueueStatus(QS_ALLINPUT)
that includes QS_RAWINPUT, and therefore would fail as well on e.g.
Windows 2000...)
Otherwise, an observable effect is that some versions of libgdk-win32-2.0.0.dll
enter into an infinite loop when calling GetQueueStatus(QS_ALLINPUT),
since this call always failed on ReactOS.
On the other side, however, we should honour our winetests that handle
the presence of the QS_RAWINPUT flag and behave differently accordingly.
But since we do not support QS_RAWINPUT yet, we should keep their old
behaviour where QS_RAWINPUT is unused.
Thus, in order to accomodate both sides, we don't fail the GetQueueStatus()
call, but just set the ERROR_INVALID_FLAGS last error and continue it.
This fixes CORE-15686, CORE-17551 and probably CORE-11850.
Fixes also all user32:TrackMouseEvent tests.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
CORE-15147
- Rename CLIENTTHREADINFO::tickLastMsgChecked into timeLastRead as
documented in https://reactos.org/wiki/Techwiki:Win32k/CLIENTTHREADINFO .
This is the last time the message queue was read.
- This is the structure member one must compare against the current tick
count timestamp in order to heuristically determine whether a message
queue thread is hung!! Fix MsqIsHung() in accordance, add extra debug
logging in order to help us determining which of our code present
regular GUI hangs, and add as well an extra "TimeOut" parameter so as
not to hardcode a fixed value within that function but instead
allowing its caller to specify possible different values.
- THREADINFO::timeLast is on the contrary the last message time stamp,
and will definitively differ from CLIENTTHREADINFO::timeLastRead .
It should only be used for information purposes!
- Accordingly, in NtUserGetThreadState()::THREADSTATE_UPTIMELASTREAD
and in InitThreadCallback(), only (re-)initialize the timeLastRead
member of the CLIENTTHREADINFO structure of the THREADINFO of interest.
- In co_IntPeekMessage(), update more often the timeLastRead timestamp
whenever the current message queue has been read (but NOT timeLast!!
That one will be updated ONLY WHEN a message is found!).
- In co_IntSendMessageTimeoutSingle() first check whether the window to
which we send the message is being destroyed, before checking for
queue hangs etc. Collapse the logic checks for queue hang and increase
the hang timeout check to 4 times MSQ_HUNG (== 4 * 5 seconds) and
display a debug trace.
SendNotifyMessageW: It doesn't support messages with pointers so there is no need to call MsgiUMToKMMessage
SendMessageTimeoutW, SendMessageTimeoutA: These two do support marshaling pointers so they need to use MsgiUMToKMMessage.
This is actually a bug that happens only in the rare case where we send a WM_COPYDATA with a timeout.
