And send_hardware_message.
This makes it possible to use __wine_send_input to send extended input
data, such as HID device notifications and WM_INPUT messages carrying
HID reports.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50506
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Calling get_input_codepage involves doing quite a lot of things, and
doing it for every message type, when it's not needed, is inefficient.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
WM_DEVICECHANGE's lParam can be either a pointer to a variant of
DEV_BROADCAST_HDR or an immediate value (usually 0) depending on
the wParam's value.
This fixes a crash when broadcasting WM_DEVICECHANGE with
wParam = DBT_DEVNODES_CHANGED, lParam = 0.
Signed-off-by: Arkadiusz Hiler <ahiler@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>
Allows Wine internal messages with pointer arguments to be sent
asynchronously.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This can't be done properly without support from the native windowing
system. However, it's a good bet to try the next window in the z-order
if it's the owner of the original window and it's in the same thread.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The basic problem is this: Thread A has a window W1 that is it's focus
window and the system-global foreground window. At some point thread A
stops processing messages. After that, thread B creates a window W2
and makes it the foreground window. Thread B later on makes W1 (from
Thread A) the foreground window again. After restoring W1 as the
foreground window, Thread A processes window messages again. Two
WM_WINE_SETACTIVEWINDOW messages are in the queue, one for losing the
foreground thread propery and one for restoring it. The first one will
generates a WM_ACTIVATEAPP(0) message, which causes D3D to minimize
the game window.
The included test shows that Windows doesn't deliver any
WM_ACTIVATEAPP messages if the thread stopped being the foreground
thread and re-gained that property between two message processing
calls. It isn't implemented with a plain WM_ACTIVATEAPP filter, the
manually injected message in the test still gets through.
Signed-off-by: Stefan Dösinger <stefan@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>