Instead of calling SendMessage, similarly to the SW_HIDE case.
Based on a patch by Kimmo Myllyvirta <kimmo.myllyvirta@gmail.com>.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=39731
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Having a __wine_display_device_guid property in the desktop window only guarantees that the window
is created. Explorer.exe still has to finish setting up virtual desktop, display settings etc.
load_desktop_driver() needs to make sure that the desktop initialization is done before allowing
applications to call user32 driver functions. Otherwise, they might get incorrect data. This race
condition became apparent after aadae4d1ea, which adds ~100ms to the
initialization process.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49762
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This allows games like solitaire, chess titans, etc. to
use animations.
Signed-off-by: Fabian Maurer <dark.shadow4@web.de>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's already some in dinput, but this is a more appropriate location.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Although most of the older Windows versions allow changing to a 1Hz display mode, it returns failure
on Windows 10 1909+.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
EnumDisplaySettings() on Wine does not write beyond the end of DEVMODE because it doesn't use
dmDriverExtra currently, but this implementation detail should not be relied on.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zero initialize DEVMODE before passing it to EnumDisplaySettings(), which may write beyond the end
of the DEVMODE structure on Windows because the dmDriverExtra field is uninitialized.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression introduced by
08bf605acb.
It could lead to stack corruption because ret can be negative when the
output position, p, doesn't point the beginning of the buffer before
the inner loop.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
ERROR_INVALID_HANDLE or ERROR_INVALID_MONITOR_HANDLE is from
GetMonitorInfo(), not EnumDisplayMonitor().
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes the GetRawInputData regression introduced with
359ee2ecc2 where the message data couldn't
be read twice, while keeping the overwrite logic it introduced.
This also adds some SetLastError to fix some unit tests todos.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49522
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This flag allows applications to receive rawinput messages while in
background. They have to specify a target hwnd, which will receive them,
and the messages will carry a RIM_INPUTSINK wparam if the process wasn't
foreground.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This makes legacy mouse window messages such as WM_MOUSEMOVE and others,
to stop being sent, including to low-level hooks. The desktop mouse
state should still be udpated.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This delivers the rawinput messages to the correct process, regardless
of where the input was received.
As for now RIDEV_INPUTSINK is still not implemented, this only fixes
the case where input is injected in a background process and where it
should not receive rawinput -as in the test- or when cursor moves over
a background window and the foreground process should have received
rawinput messages.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Another thread is created to execute the tests, for SetThreadDesktop to
succeed consistently. It seems to fail spuriously if it is called from
a thread that already created some windows before.
This shows that rawinput messages may be dispatched across desktops,
but only if the subscribing process has a window in the input desktop,
and it is the foreground process (even if the target window may be in
another desktop).
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When RIM_EXINPUTSINK is used, messages are received in background
only if the foreground process didn't register for rawinput messages
itself.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zhiyi Zhang