November 2021 - Wine-Devel - list.winehq.org

[PATCH v2 2/2] kernel32: Forward AppPolicyGetMediaFoundationCodecLoading to kernelbase.

by Mohamad Al-Jaf

Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com> --- dlls/kernel32/kernel32.spec | 1 + 1 file changed, 1 insertion(+) diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec index 90b503af19f..156da3a78a2 100644 --- a/dlls/kernel32/kernel32.spec +++ b/dlls/kernel32/kernel32.spec @@ -157,6 +157,7 @@ @ stdcall -import AllocateUserPhysicalPagesNuma(long ptr ptr long) @ stdcall ApplicationRecoveryFinished(long) @ stdcall ApplicationRecoveryInProgress(ptr) +@ stdcall AppPolicyGetMediaFoundationCodecLoading(ptr ptr) kernelbase.AppPolicyGetMediaFoundationCodecLoading @ stdcall -import AreFileApisANSI() @ stdcall AssignProcessToJobObject(ptr ptr) @ stdcall -import AttachConsole(long) -- 2.33.1

Nov. 11, 2021

[PATCH v2 1/2] kernelbase: Implement AppPolicyGetMediaFoundationCodecLoading.

by Mohamad Al-Jaf

Enables native Windows 10 media foundation libraries to run. Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com> --- v2: Add missing function prototype. --- .../api-ms-win-appmodel-runtime-l1-1-2.spec | 2 +- dlls/kernelbase/kernelbase.spec | 2 +- dlls/kernelbase/main.c | 14 ++++++++++++++ include/appmodel.h | 7 +++++++ 4 files changed, 23 insertions(+), 2 deletions(-) diff --git a/dlls/api-ms-win-appmodel-runtime-l1-1-2/api-ms-win-appmodel-runtime-l1-1-2.spec b/dlls/api-ms-win-appmodel-runtime-l1-1-2/api-ms-win-appmodel-runtime-l1-1-2.spec index 3c1b4058a9f..89fe702bbc2 100644 --- a/dlls/api-ms-win-appmodel-runtime-l1-1-2/api-ms-win-appmodel-runtime-l1-1-2.spec +++ b/dlls/api-ms-win-appmodel-runtime-l1-1-2/api-ms-win-appmodel-runtime-l1-1-2.spec @@ -1,7 +1,7 @@ @ stub AppPolicyGetClrCompat @ stub AppPolicyGetCreateFileAccess @ stub AppPolicyGetLifecycleManagement -@ stub AppPolicyGetMediaFoundationCodecLoading +@ stdcall AppPolicyGetMediaFoundationCodecLoading(ptr ptr) kernelbase.AppPolicyGetMediaFoundationCodecLoading @ stdcall AppPolicyGetProcessTerminationMethod(ptr ptr) kernelbase.AppPolicyGetProcessTerminationMethod @ stdcall AppPolicyGetShowDeveloperDiagnostic(ptr ptr) kernelbase.AppPolicyGetShowDeveloperDiagnostic @ stdcall AppPolicyGetThreadInitializationType(ptr ptr) kernelbase.AppPolicyGetThreadInitializationType diff --git a/dlls/kernelbase/kernelbase.spec b/dlls/kernelbase/kernelbase.spec index dd9f4a8ddce..55208889c35 100644 --- a/dlls/kernelbase/kernelbase.spec +++ b/dlls/kernelbase/kernelbase.spec @@ -43,7 +43,7 @@ # @ stub AppPolicyGetClrCompat # @ stub AppPolicyGetCreateFileAccess # @ stub AppPolicyGetLifecycleManagement -# @ stub AppPolicyGetMediaFoundationCodecLoading +@ stdcall AppPolicyGetMediaFoundationCodecLoading(ptr ptr) @ stdcall AppPolicyGetProcessTerminationMethod(ptr ptr) @ stdcall AppPolicyGetShowDeveloperDiagnostic(ptr ptr) @ stdcall AppPolicyGetThreadInitializationType(ptr ptr) diff --git a/dlls/kernelbase/main.c b/dlls/kernelbase/main.c index b90ee1cba2c..e6cf892a4dc 100644 --- a/dlls/kernelbase/main.c +++ b/dlls/kernelbase/main.c @@ -88,6 +88,20 @@ INT WINAPI MulDiv( INT a, INT b, INT c ) return ret; } +/*********************************************************************** + * AppPolicyGetMediaFoundationCodecLoading (KERNELBASE.@) + */ + +LONG WINAPI AppPolicyGetMediaFoundationCodecLoading(HANDLE token, AppPolicyMediaFoundationCodecLoading *policy) +{ + FIXME("%p, %p\n", token, policy); + + if(policy) + *policy = AppPolicyMediaFoundationCodecLoading_All; + + return ERROR_SUCCESS; +} + /*********************************************************************** * AppPolicyGetProcessTerminationMethod (KERNELBASE.@) */ diff --git a/include/appmodel.h b/include/appmodel.h index e4288bbfbb0..8c219e8080a 100644 --- a/include/appmodel.h +++ b/include/appmodel.h @@ -22,6 +22,12 @@ extern "C" { #endif +typedef enum AppPolicyMediaFoundationCodecLoading +{ + AppPolicyMediaFoundationCodecLoading_All = 0, + AppPolicyMediaFoundationCodecLoading_InboxOnly = 1, +} AppPolicyMediaFoundationCodecLoading; + typedef enum AppPolicyProcessTerminationMethod { AppPolicyProcessTerminationMethod_ExitProcess = 0, @@ -78,6 +84,7 @@ typedef struct PACKAGE_ID } PACKAGE_ID; +LONG WINAPI AppPolicyGetMediaFoundationCodecLoading(HANDLE token, AppPolicyMediaFoundationCodecLoading *policy); LONG WINAPI AppPolicyGetProcessTerminationMethod(HANDLE token, AppPolicyProcessTerminationMethod *policy); LONG WINAPI AppPolicyGetShowDeveloperDiagnostic(HANDLE token, AppPolicyShowDeveloperDiagnostic *policy); LONG WINAPI AppPolicyGetThreadInitializationType(HANDLE token, AppPolicyThreadInitializationType *policy); -- 2.33.1

Nov. 11, 2021

Re: [PATCH] kernelbase: Implement AppPolicyGetMediaFoundationCodecLoading.

by Nikolay Sivov

On 11/11/21 9:05 AM, Mohamad Al-Jaf wrote: > Hi Nikolay, > > Thanks for the feedback. > > I'm not sure what you mean by forward, is it in the spec file? Or are > you referring to forward declaration? Sorry, I'm new to wine > development and have no idea, but I'm assuming you mean the spec file > because I see stdcalls that are being forwarded to kernelbase. > > Regardless, I did not see any mention of AppPolicy in kernel32 so I > added the existing AppPolicy functions as well. This is in > kernel32.spec, is it correct? I don't want to submit a broken patch > and waste the dev team's time. > > @ stdcall AppPolicyGetMediaFoundationCodecLoading(ptr ptr) > kernelbase.AppPolicyGetMediaFoundationCodecLoading > @ stdcall AppPolicyGetProcessTerminationMethod(ptr ptr) > kernelbase.AppPolicyGetProcessTerminationMethod > @ stdcall AppPolicyGetShowDeveloperDiagnostic(ptr ptr) > kernelbase.AppPolicyGetShowDeveloperDiagnostic > @ stdcall AppPolicyGetThreadInitializationType(ptr ptr) > kernelbase.AppPolicyGetThreadInitializationType > @ stdcall AppPolicyGetWindowingModel(ptr ptr) > kernelbase.AppPolicyGetWindowingModel Yes, that's how it's done. For your patch just add AppPolicyGetMediaFoundationCodecLoading for now. > > Great, so the code in kernelbase/main is correct? What do you mean by > 'unpackaged binary'? How did you test it? I'm trying to learn as much > as I can about wine development. Yes, it seems to work. I haven't checked if it does null argument validation, but it does return _All on windows. My unpackaged I mean regular standalone exe. As I understand all of AppPolicy* are meant for appx bundles, don't know how they are created or what's in there. But from some docs it must be binary packaged together with some metadata, with some signing I guess. With that metadata you can control what's allowed and what's not, and shared code then can use AppPolicy* to access this configuration. > > I'll submit a revision for the function prototype, sorry about that. > > Kind regards, > Mohamad > > On Wed, Nov 10, 2021 at 7:24 AM Nikolay Sivov <nsivov(a)codeweavers.com > <mailto:nsivov(a)codeweavers.com>> wrote: > > > > On 11/9/21 4:57 AM, Mohamad Al-Jaf wrote: > > Enables native Windows 10 media foundation libraries to run. > > > > Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com > <mailto:mohamadaljaf(a)gmail.com>> > > --- > > .../api-ms-win-appmodel-runtime-l1-1-2.spec | 2 +- > > dlls/kernelbase/kernelbase.spec | 2 +- > > dlls/kernelbase/main.c | 14 > ++++++++++++++ > > include/appmodel.h | 6 ++++++ > > 4 files changed, 22 insertions(+), 2 deletions(-) > > Apparently kernel32 also has AppPolicy exports, please add a forward > there too. > > > diff --git a/dlls/kernelbase/main.c b/dlls/kernelbase/main.c > > index b90ee1cba2c..e6cf892a4dc 100644 > > --- a/dlls/kernelbase/main.c > > +++ b/dlls/kernelbase/main.c > > @@ -88,6 +88,20 @@ INT WINAPI MulDiv( INT a, INT b, INT c ) > > return ret; > > } > > > > > +/*********************************************************************** > > + * AppPolicyGetMediaFoundationCodecLoading (KERNELBASE.@) > > + */ > > + > > +LONG WINAPI AppPolicyGetMediaFoundationCodecLoading(HANDLE > token, AppPolicyMediaFoundationCodecLoading *policy) > > +{ > > + FIXME("%p, %p\n", token, policy); > > + > > + if(policy) > > + *policy = AppPolicyMediaFoundationCodecLoading_All; > > + > > + return ERROR_SUCCESS; > > +} > > Thanks, this seems to match what unpackaged binary gets according > to my > quick test, so that's good. > > > + > > > /*********************************************************************** > > * AppPolicyGetProcessTerminationMethod (KERNELBASE.@) > > */ > > diff --git a/include/appmodel.h b/include/appmodel.h > > index e4288bbfbb0..cf1b9659d14 100644 > > --- a/include/appmodel.h > > +++ b/include/appmodel.h > > @@ -22,6 +22,12 @@ > > extern "C" { > > #endif > > > > +typedef enum AppPolicyMediaFoundationCodecLoading > > +{ > > + AppPolicyMediaFoundationCodecLoading_All = 0, > > + AppPolicyMediaFoundationCodecLoading_InboxOnly = 1, > > +} AppPolicyMediaFoundationCodecLoading; > > + > > typedef enum AppPolicyProcessTerminationMethod > > { > > AppPolicyProcessTerminationMethod_ExitProcess = 0, > Please add function prototype as well. >

Nov. 11, 2021

[PATCH] shell32: Check This->sPathTarget before calling get_display_name().

by Zhiyi Zhang

Fix Excel 2010 crashing in get_display_name() when clicking the ribbon bar file tab. The check was removed in 984f608. Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> --- dlls/shell32/shfldr_fs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/dlls/shell32/shfldr_fs.c b/dlls/shell32/shfldr_fs.c index 64571200493..214b9326342 100644 --- a/dlls/shell32/shfldr_fs.c +++ b/dlls/shell32/shfldr_fs.c @@ -867,8 +867,9 @@ IShellFolder_fnGetDisplayNameOf (IShellFolder2 * iface, LPCITEMIDLIST pidl, if ((GET_SHGDN_FOR(dwFlags) & SHGDN_FORPARSING) && (GET_SHGDN_RELATION(dwFlags) != SHGDN_INFOLDER)) { - get_display_name( pszPath, This->sPathTarget, pidl, - IsEqualCLSID( This->pclsid, &CLSID_UnixFolder )); + if (This->sPathTarget) + get_display_name( pszPath, This->sPathTarget, pidl, + IsEqualCLSID( This->pclsid, &CLSID_UnixFolder )); } else { /* pidl has to contain exactly one non null SHITEMID */ hr = E_INVALIDARG; -- 2.32.0

Nov. 11, 2021

Re: [PATCH vkd3d 2/5] vkd3d-shader/hlsl: Perform a copy propagation pass.

by Giovanni Mascellani

Hi, On 10/11/21 17:33, Zebediah Figura (she/her) wrote: >> Mmh, note that you have to handle control flow in some way or another, >> you cannot just ignore it. This patch doesn't know about control flow, >> but the only way it can do it is by bailing out at the first control >> flow instruction in the program. It's not enough to ignore the control >> flow block and resume processing after it, because the inner block >> might invalidate some of your knowledge about the program state (in >> 3/5 patch this is done by copy_propagation_invalidate_from_block). > > Right. I should have said to invalidate the whole copyprop state both > when entering a CF block and when leaving one. The point is that we can > do copyprop within every BB, not just the first one, without having to > worry about things like partial invalidation. I guess that by now I've already read the other mail I sent on that, but the point is that wouldn't be enough to get texture working, I think. >> Personally I would have loved to meet comments like mine in other >> areas of Wine: knowing what data read or written by an algorithm are >> meant to represent makes it much easier to understand why the >> algorithm does what it does. I agree that this is not the most >> complicated case around, but I thought this would be helpful for >> someone not already knowing my code. OTOH I understand that also a >> high-level description is useful: would you consider it satisfying to >> have both? > > Eh, maybe. I would at least start with the high-level explanation. When > I read the above comment my eyes kind of glaze over, and it doesn't tell > me anything that the code already doesn't (even the struct definitions > alone tell me as much without checking how they're used.) > > I dunno, I'll see what you end up coming up with. Ok, I'll do my best. > Er, sorry, I should have said intptr_t. I mean to return intptr_t from > the rbtree compare callback, and then all you need is > > return (intptr_t)key - (intptr_t) variable->var; Would that really work? For one thing, signed overflow is undefined behavior in C (except possibly very recent versions which we're definitely not using). It doesn't seem we're using -fwrapv, does it? Even assuming two's complement semantics, this doesn't seem to give an order: for example, 0 > (INT_MIN + 1), because 0 - (INT_MIN + 1) = INT_MAX > 0 and INT_MAX > 0, because INT_MAX - 0 = INT_MAX > 0, but (INT_MIN + 1) - INT_MAX = 2 > 0, therefore you'd have (INT_MIN + 1) > INT_MAX. Therefore the relationship is not transitive, which I am pretty sure the red-black tree implementation won't like. Am I missing something? > Ah. I assumed that you would actually be indexing right before copyprop, > and didn't check whether that was actually the case. > > Although on reflection now I'm not sure if we *should* index. We only > dump the IR once, at the end, and I feel like we risk confusion by > printing instruction indices that won't match. Hmm, maybe the code makes > sense as it is... You're right, I'd say at this point it's better to just ignore the index and always use the pointer, so there is no confusion with the indices in the final dump. This also means that I can put the %p directly in the TRACE without the additional buffer that you didn't like (and removing like 10 lines of code used just for tracing). > I'm typically in favor of leaving in traces if they were helpful during > debugging. > > For what it's worth, I'd also be in favor of a "debugstr_node" helper or > something. Maybe even if it uses a fixed-size buffer, although I'm not > sure that Matteo or Henri will agree with that ;-) If you accept my solution above, this has just been swept away. >>> Shouldn't this function just return void? >> >> It's a matter of philosophy. If you ask me, the switch in >> copy_propagation_recursive should be rather oblivious of what the >> various helpers actually do, it shouldn't have an insight that >> copy_propagation_store never returns true. For its point of view, any >> helper can potentially modify the code. Though I can change to void if >> you prefer. > > It's a fair point, but I guess I look at copy_propagation_recursive() > and think "recording stores should never make any progress; all the > magic happens in rewriting loads". This becomes especially true if this > function gets renamed to copy_prop_record_store() or something, which I > think it should. Ok, you win on this one. Thanks again, Giovanni.

Nov. 11, 2021

Re: [PATCH v6 1/2] ntdll: Allow loading system DLLs from a path specified at configure time.

by Alexandre Julliard

Zebediah Figura <zfigura(a)codeweavers.com> writes: > Many distributions provide MinGW-compiled system DLLs which are currently > bundled with Wine. Unfortunately, while MinGW pkg-config can be used to detect > the linking path, there is no standardized runtime path, and many distributions > in fact use different paths. I think it needs to be a proper path containing multiple directories, at least to allow supporting both 32- and 64-bit dlls. Otherwise there would need to be some sort of mapping from PE architecture to system dir. -- Alexandre Julliard julliard(a)winehq.org

Nov. 11, 2021

Re: [PATCH v2 2/5] user32: Use user_driver_funcs to expose user driver function from drivers.

by Huw Davies

On Wed, Nov 10, 2021 at 01:33:32PM +0100, Jacek Caban wrote: > diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c > index 7b51823014d..ed7cc5c72ba 100644 > --- a/dlls/user32/driver.c > +++ b/dlls/user32/driver.c > @@ -59,9 +59,16 @@ static BOOL load_desktop_driver( HWND hwnd, HMODULE *module ) > size = sizeof(path); > if (!RegQueryValueExW( hkey, L"GraphicsDriver", NULL, NULL, (BYTE *)path, &size )) > { > - if ((ret = !wcscmp( path, L"null" ))) *module = NULL; > - else ret = (*module = LoadLibraryW( path )) != NULL; > - if (!ret) ERR( "failed to load %s\n", debugstr_w(path) ); > + if (wcscmp( path, L"null" )) > + { > + ret = LoadLibraryW( path ) != NULL; > + if (!ret) ERR( "failed to load %s\n", debugstr_w(path) ); > + } > + else > + { > + __wine_set_user_driver( &null_driver, WINE_GDI_DRIVER_VERSION ); > + ret = TRUE; > + } > TRACE( "%s %p\n", debugstr_w(path), *module ); This doesn't look quite right as "module" is now unused (I realise it's eliminated in the next patch, but it would be nice to have this patch make sense too). This leads to: i686-w64-mingw32-gcc -c -o dlls/user32/driver.cross.o dlls/user32/driver.c -Idlls/user32 -Iinclude -Iinclude/msvcrt -I./libs/png \ -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_UCRT -D__WINE_PE_BUILD -Wall -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self \ -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value \ -fno-omit-frame-pointer -gdwarf-2 -gstrict-dwarf -g -O2 In file included from dlls/user32/driver.c:27: dlls/user32/driver.c: In function ‘load_driver’: include/wine/debug.h:89:5: warning: ‘module’ may be used uninitialized in this function [-Wmaybe-uninitialized] 89 | wine_dbg_log( __dbcl, __dbch, __FUNCTION__, args); } } while(0) | ^~~~~~~~~~~~ > diff --git a/dlls/winemac.drv/gdi.c b/dlls/winemac.drv/gdi.c > index 3148e28afdd..db5cd1b8810 100644 > --- a/dlls/winemac.drv/gdi.c > +++ b/dlls/winemac.drv/gdi.c > @@ -57,7 +57,7 @@ static CRITICAL_SECTION_DEBUG critsect_debug = > static CRITICAL_SECTION device_data_section = { &critsect_debug, -1, 0, 0, 0, 0 }; > > > -static const struct gdi_dc_funcs macdrv_funcs; > +static const struct user_driver_funcs macdrv_funcs; > > /*********************************************************************** > * compute_desktop_rect > @@ -184,7 +184,7 @@ static BOOL CDECL macdrv_CreateDC(PHYSDEV *pdev, LPCWSTR device, LPCWSTR output, > > if (!physDev) return FALSE; > > - push_dc_driver(pdev, &physDev->dev, &macdrv_funcs); > + push_dc_driver(pdev, &physDev->dev, &macdrv_funcs.dc_funcs); > return TRUE; > } > > @@ -201,7 +201,7 @@ static BOOL CDECL macdrv_CreateCompatibleDC(PHYSDEV orig, PHYSDEV *pdev) > > if (!physDev) return FALSE; > > - push_dc_driver(pdev, &physDev->dev, &macdrv_funcs); > + push_dc_driver(pdev, &physDev->dev, &macdrv_funcs.dc_funcs); > return TRUE; > } You forgot to change macdrv_get_gdi_driver() to avoid this: gcc -m32 -c -o dlls/winemac.drv/gdi.o dlls/winemac.drv/gdi.c -Idlls/winemac.drv -Iinclude -D__WINESRC__ -fPIC \ -fasynchronous-unwind-tables -Wall -pipe -fno-stack-protector -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self -Wno-pragma-pack \ -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -O2 -g -Wno-deprecated-declarations -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 dlls/winemac.drv/gdi.c:324:12: warning: incompatible pointer types returning 'const struct user_driver_funcs *' from a function with result type 'const struct gdi_dc_funcs *' [-Wincompatible-pointer-types] return &macdrv_funcs; (I'd have fixed this up myself, if that had been the only issue). Thanks, Huw.

Nov. 11, 2021

Re: [PATCH v2 1/5] user32: Introduce user_driver_funcs struct.

by Huw Davies

On Wed, Nov 10, 2021 at 01:33:01PM +0100, Jacek Caban wrote: > > And use it instead of USER_DRIVER. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/user32/driver.c | 24 +++++++-------- > dlls/user32/painting.c | 9 ++---- > dlls/user32/sysparams.c | 1 - > dlls/user32/user_private.h | 56 ++-------------------------------- > dlls/user32/win.c | 6 +--- > dlls/user32/winpos.c | 9 ++---- > include/wine/gdi_driver.h | 61 ++++++++++++++++++++++++++++++++++++++ > 7 files changed, 78 insertions(+), 88 deletions(-) Hi Jacek, This is causing a build failure on macOS: gcc -m32 -c -o dlls/winemac.drv/mouse.o dlls/winemac.drv/mouse.c -Idlls/winemac.drv -Iinclude -D__WINESRC__ -fPIC \ -fasynchronous-unwind-tables -Wall -pipe -fno-stack-protector -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self -Wno-pragma-pack \ -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -O2 -g -Wno-deprecated-declarations -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 dlls/winemac.drv/mouse.c:55:7: error: use of undeclared identifier 'OCR_NORMAL' { OCR_NORMAL, CFSTR("arrowCursor") }, ^ dlls/winemac.drv/mouse.c:56:7: error: use of undeclared identifier 'OCR_IBEAM' { OCR_IBEAM, CFSTR("IBeamCursor") }, ^ I would have fixed this up myself (the fix is actually in [2/5]), but there were other issues with [2/5]. Huw.

Nov. 11, 2021

[PATCH 6/6] comctl32/button: Support BS_PUSHLIKE for themed command links.

by Zhiyi Zhang

Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> --- dlls/comctl32/button.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/dlls/comctl32/button.c b/dlls/comctl32/button.c index f158a7423b9..2e3d8912a66 100644 --- a/dlls/comctl32/button.c +++ b/dlls/comctl32/button.c @@ -3040,6 +3040,7 @@ static void CL_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in NMCUSTOMDRAW nmcd; LRESULT cdrf; HWND parent; + int part; RECT rc; if (infoPtr->font) SelectObject(hDC, infoPtr->font); @@ -3054,9 +3055,10 @@ static void CL_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in cdrf = SendMessageW(parent, WM_NOTIFY, nmcd.hdr.idFrom, (LPARAM)&nmcd); if (cdrf & CDRF_SKIPDEFAULT) return; - if (IsThemeBackgroundPartiallyTransparent(theme, BP_COMMANDLINK, state)) + part = GetWindowLongW(infoPtr->hwnd, GWL_STYLE) & BS_PUSHLIKE ? BP_PUSHBUTTON : BP_COMMANDLINK; + if (IsThemeBackgroundPartiallyTransparent(theme, part, state)) DrawThemeParentBackground(infoPtr->hwnd, hDC, NULL); - DrawThemeBackground(theme, hDC, BP_COMMANDLINK, state, &rc, NULL); + DrawThemeBackground(theme, hDC, part, state, &rc, NULL); if (cdrf & CDRF_NOTIFYPOSTERASE) { @@ -3076,7 +3078,7 @@ static void CL_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in SIZE img_size; WCHAR *text; - GetThemeBackgroundContentRect(theme, hDC, BP_COMMANDLINK, state, &rc, &r); + GetThemeBackgroundContentRect(theme, hDC, part, state, &rc, &r); /* The text alignment and styles are fixed and don't depend on button styles */ dtFlags = DT_TOP | DT_LEFT | DT_WORDBREAK; @@ -3096,10 +3098,9 @@ static void CL_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in UINT len = lstrlenW(text); RECT text_rect; - GetThemeTextExtent(theme, hDC, BP_COMMANDLINK, state, text, len, - dtFlags | DT_END_ELLIPSIS, &r, &text_rect); - DrawThemeText(theme, hDC, BP_COMMANDLINK, state, text, len, - dtFlags | DT_END_ELLIPSIS, 0, &r); + GetThemeTextExtent(theme, hDC, part, state, text, len, dtFlags | DT_END_ELLIPSIS, &r, + &text_rect); + DrawThemeText(theme, hDC, part, state, text, len, dtFlags | DT_END_ELLIPSIS, 0, &r); txt_h = text_rect.bottom - text_rect.top; heap_free(text); @@ -3114,8 +3115,7 @@ static void CL_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in opts.dwSize = sizeof(opts); opts.dwFlags = DTT_FONTPROP; opts.iFontPropId = TMT_BODYFONT; - DrawThemeTextEx(theme, hDC, BP_COMMANDLINK, state, - infoPtr->note, infoPtr->note_length, + DrawThemeTextEx(theme, hDC, part, state, infoPtr->note, infoPtr->note_length, dtFlags | DT_NOPREFIX, &r, &opts); } -- 2.32.0

Nov. 11, 2021

[PATCH 5/6] comctl32/button: Support BS_PUSHLIKE for themed group boxes.

by Zhiyi Zhang

Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> --- dlls/comctl32/button.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/dlls/comctl32/button.c b/dlls/comctl32/button.c index 74de83b461a..f158a7423b9 100644 --- a/dlls/comctl32/button.c +++ b/dlls/comctl32/button.c @@ -448,7 +448,7 @@ static int get_draw_state(const BUTTON_INFO *infoPtr) return style & BS_PUSHLIKE ? pushlike_rb_states[check_state][state] : rb_states[check_state][state]; case BS_GROUPBOX: - return gb_states[state]; + return style & BS_PUSHLIKE ? pb_states[state] : gb_states[state]; default: WARN("Unsupported button type 0x%08x\n", type); return PBS_NORMAL; @@ -2883,6 +2883,7 @@ static void GB_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in HFONT font, hPrevFont = NULL; BOOL created_font = FALSE; TEXTMETRICW textMetric; + int part; HRESULT hr = GetThemeFont(theme, hDC, BP_GROUPBOX, state, TMT_FONT, &lf); if (SUCCEEDED(hr)) { @@ -2914,9 +2915,10 @@ static void GB_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in ExtSelectClipRgn(hDC, textRegion, RGN_DIFF); } - if (IsThemeBackgroundPartiallyTransparent(theme, BP_GROUPBOX, state)) + part = GetWindowLongW(infoPtr->hwnd, GWL_STYLE) & BS_PUSHLIKE ? BP_PUSHBUTTON : BP_GROUPBOX; + if (IsThemeBackgroundPartiallyTransparent(theme, part, state)) DrawThemeParentBackground(infoPtr->hwnd, hDC, NULL); - DrawThemeBackground(theme, hDC, BP_GROUPBOX, state, &bgRect, NULL); + DrawThemeBackground(theme, hDC, part, state, &bgRect, NULL); if (dtFlags != (UINT)-1) { @@ -2928,7 +2930,7 @@ static void GB_ThemedPaint(HTHEME theme, const BUTTON_INFO *infoPtr, HDC hDC, in SelectClipRgn(hDC, textRegion); DeleteObject(textRegion); } - BUTTON_DrawThemedLabel(infoPtr, hDC, dtFlags, &imageRect, &textRect, theme, BP_GROUPBOX, state); + BUTTON_DrawThemedLabel(infoPtr, hDC, dtFlags, &imageRect, &textRect, theme, part, state); } SelectClipRgn(hDC, region); -- 2.32.0

Nov. 11, 2021