Rectangle used for invalidation was outside of windows rect of static
controls with SS_ETCHEDHORZ/SS_ETCHEDVERT style because they resize
after creation. Improve test by changing the invalidated rect and
add more details in comment about SS_ETCHEDHORZ/SS_ETCHEDVERT styles.
Signed-off-by: Rafał Harabień <rafalh92@outlook.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of drawing the frame in WM_PAINT use WS_EX_STATICEDGE style that
adds the frame outside of the client rect and change control size after
creation to make it look like a line.
Signed-off-by: Rafał Harabień <rafalh92@outlook.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Also change 'BOOL ret' to 'LRESULT ret' to avoid introducing new
variable for DefWindowProc() return value checks in the next patch.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fix foobar2000 wrong scroll bar size box color when theming is on.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The test gets spurious GetScrollInfo SB_HORZ failures if some other
windows were created before using CW_USEDEFAULT positions, for instance
the window from test_capture_4.
This happened on some Win10 VMs, and was thought to be fixed with
9b5346df86bf1a85336ed03a67a630970ce08e9f, but it then broke the test on
some other VMs. This is hopefully a better fix, and it reverts the
previous one too.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=52507
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Can be reproduced randomly even without user32:monitor, for instance
running user32:win in a fresh Win7 VM.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=51392
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Shows that it switches focus to some other process window and back, and
only on some older Windows versions. Win10 simply returns 0 and does
nothing.
Stop calling it elsewhere, as it makes focus go to an unpredictable
window, which may very well not be ours.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=51391
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=51130
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When an application handles WM_NCPAINT by itself, standard scroll bars are not drawn even if
WS_HSCROLL or WS_VSCROLL is used. In this case, when handling WM_NCMOUSEMOVE, DefWinProc() shouldn't
repaint standard scroll bars to reflect hovered state, otherwise, DefWinProc() draws over the custom
non-client area painted by the application. This is also the behavior on XP.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51900
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Mostly to test that standard scroll bars doesn't get painted in hovered state if they weren't
previously painted by DefWinProcA/W().
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When changing DPI, a "fix blurry apps" popup may appear on Windows 10. The popup may interfere with
other tests as it steals focus, causing them to fail. So set IgnorePerProcessSystemDPIToast to 1 to
temporarily disable the popup.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52108
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
DefWindowProc() does not propagate the wparam; it updates it instead.
Spotted by YAL.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52327
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Device context bit depths other than 32-bit are emulated and the real bit depth for display DCs is
still 32-bit. Thus, a 32-bit DDB should be allowed to be selected into a display compatible DC even
if the DC reports a different bit depth.
Fix a regression from d171d11.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51805
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The given bitmap is in DDB format, not DIB format.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51296
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For icons/cursors created by CreateIconFromResource(),
GetIconInfo() still succeed after they were destroyed,
which indicates that these icons/cursors are shared.
Signed-off-by: Ziqing Hui <zhui@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It makes sure that shared icon/cursor created by CreateIconFromResourceEx()
won't be destroyed by Destroy{Icon,Cursor}().
Signed-off-by: Ziqing Hui <zhui@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The tests show that shared icon created by CreateIconFromResourceEx()
won't be destroyed by DestroyIcon(). However, a second call to it for the
same icon bits will return a different handle.
Signed-off-by: Ziqing Hui <zhui@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
ALT and F10 key generate WM_SYSKEYDOWN message.
They should also have the ability to queue hotkey message.
Signed-off-by: Ziqing Hui <zhui@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's an application that calls DragDetect() on every WM_MOUSEMOVE
message, and this breaks handling of mouse events. A simple test app
shows that on Windows DragDetect() starts its message loop when left
mouse button is pressed.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rafał Harabień