depending on the files, these macros can be called with:
- UINT/UINT, DWORD/DWORD pairs, but also UINT/DWORD or DWORD/UINT pairs...
- wrapping inside an inline function allows the compiler to take care of
the integral conversions
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
All the notification codes (printed as an id) have negative base value
(SBN_, UDN_, HDN_, BCN_, TBN_, TTN_, RBN_, TRBN_, PGN_, TVN_, LVN_, TCN_,
CBEN_, IPN_, MCN_, DTN_), and printing them as decimal helps to quickly
identify the corresponding notification value in cases when an id in
the message sequence doesn't match. Custom ids in the message sequences
have small numbers (0, 1, 2, ...), so they also get printed correctly.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fix radio buttons of Mupen64-RR-Lua input window having stale background. Mupen64-RR-Lua doesn't actually handle
WM_ERASEBKGND even though it returns nonzero. And tests show that a WM_CTLCOLORSTATIC is sent and the returned brush
is used for filling background, even painting over the content from DrawThemeParentBackground().
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52433
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The brush from WM_CTLCOLORBTN is used for filling background for push buttons after a DrawThemeParentBackground() call
according to tests.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fix the track bar of Mupen64-RR-Lua input window having black background. Mupen64-RR-Lua doesn't actually handle
WM_ERASEBKGND even though it returns nonzero. And tests show that only WM_CTLCOLORSTATIC is sent when drawing themed
trackbar background.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Add themed background tests to determine whether DrawThemeParentBackground()
or WM_CTLCOLOR* are used to draw themed background for comctl32 classes.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The removed tests are covered by test_EnableThemeDialogTexture() in uxtheme/tests/system.c.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These tests are covered by test_EnableThemeDialogTexture() in uxtheme/tests/system.c. These tests
are also misleading because a WM_ERASEBKGND message is needed to actually activate dialog theming.
Without the message, they give the impression that EnableThemeDialogTexture() does nothing and
DefDlgProcA/W() are not hooked.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes a testbot failure on Windows 10 Hebrew.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fix a regression from 2f1bbd8 that makes the static control for DPI sample text in winecfg not
refreshing its background when moving the DPI slider.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently there is no need to hook DefDlgProc(). Tests show that dialog theming shouldn't be
implemented in DefDlgProc().
Also fix a double free bug because WM_DESTROY in UXTHEME_DefDlgProc() calls CloseThemeData() even
when the theme handle is not opened when handling WM_CREATE in UXTHEME_DefDlgProc(). The bug can
be demonstrated by running comctl32/tests/propsheet.c tests with Light theme.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Move themed WM_CTLCOLORSTATIC handling from UXTHEME_DefDlgProc() to the property sheet page window
procedure.
Fix a regression from 2f1bbd8 that makes the static controls in file open dialog to have black
background when using some themes.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51987
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These tests show that it's the themed property sheet page window procedure that sets device contexts
transparent and return a pattern brush created from the tab body part in a theme. Combined with
test_WM_CTLCOLORSTATIC() in dlls/comctl32/tests/static.c, we can conclude that UXTHEME_DefDlgProc()
shouldn't handle WM_CTLCOLORSTATIC.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Mostly to test that even when theme texture is enabled for a dialog, the default dialog procedure
still returns the stock COLOR_BTNFACE brush in response to WM_CTLCOLORSTATIC.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
SetBkMode(TRANSPARENT) already indicates that the parent background should remain untouched.
Drawing parent background destroys any previous content that applications drawn and some
applications rely on the content being unchanged.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51914
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fix Spy++ Toolbar buttons have artifacts. Spy++ first creates a Toolbar window, then calls
OpenThemeData(hwnd, "Rebar") with the Toolbar window. Then when the Toolbar control uses the theme
handle from GetWindowTheme(), it gets a Rebar theme the next time it draws, thus drawing wrong theme
parts.
According the tests, not all of the common controls have such behaviors. Some of them do have theme
handles opened by their window and then use that theme handle afterwards even it's changed from the
outside. However, for other controls, the behaviors are not very consistent across all Windows
versions. Also no applications depend on such behaviors for other controls yet. So, only modify the
Toolbar control for now.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>