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>
This prevents the tracking menu from erroneously closing itself right after it was opened in some cases.
Fixes CORE-17338 which got unhidden by 0.4.15-dev-1126-g 58b0558f94
And fixes CORE-15760 which got unhidden by SVN r74972 == git 19dd22d422
Since both symptoms look very similar but the unhiding revisions did differ,
that could mean we do have some kind of race condition here.
I guess this fix is more like a workaround. I do intend to port it back nevertheless.
As we are a non PNP driver, the call chain will be
DriverEntry -> VidePortInitialize -> VideoPortFindAdapter -> HwFindAdapter.
If legacy resources are available, we will fail VGAFindAdapter,
so DriverEntry will fail, so vgamp.sys driver won't be used.
CORE-17789
- Rewrite ImmGetImeMenuItemsA and ImmGetImeMenuItemsW functions.
- Add Imm32GetImeMenuItemsAW, Imm32IsImcAnsi, Imm32ImeMenuAnsiToWide and Imm32ImeMenuWideToAnsi helper functions.
- Make IME module's ImeGetImeMenuItems function optional.
CORE-11700
Sync/Port: Metafile code from wine.
Patches by Jacek Caban, Daniel Lehman, Zhiyi Zhang. Gabriel Ivancescu, Michael Stefaniuc, Francois Gouget, Nikolay Sivov Dmitry Timoshkov, Andrew EiKum, Piotr Caban and Alexandre Julliard.
This commit is dedicated to George Bisoc!
This is an addendum to
0.4.15-dev-3174-g dda9c3979e CORE-17769 and
0.4.15-dev-3147-g 3bf7e3ac13 CORE-17754 CORE-17755
We have not seen this happening in real-life yet, but some code-fragments within co_IntSetScrollInfo()
e.g. line 628 if (nBar == SB_CTL) do clearly indicate that nBar can be 2 (SB_CTL).
Some lines below we definitely must not access those 4 static arrays out of bounds then via nBar as access index!
Ftr with a bit of grepping I also found some calls like NtUserSetScrollInfo(Wnd, SB_CTL, &Info, FALSE);
e.g: in win32ss/user/user32/controls/scrollbar.c so I am pretty sure nBar == 2 can happen in practice within co_IntSetScrollInfo().
I question whether any of those reads/writes to those static arrays (or the comparisons) would make any sense on index 2,
so we should aim to eliminate them altogether in the future.
Fixes CORE-17769 'Rapps Listview manual resize may erroneously not draw the triangles sometimes'
This could happen for both: themed and unthemed.
CORE-17769 was a regression introduced by 0.4.14-dev-1134-g 00adb1a3f9
We don't really like the added state in form of the static variables,
but the patch works good from a pure testing-perspective.
Many Thanks to the patches author: Doug Lyons
