user32: Don't crash for unknown button styles
André Hentschel
nerv at dawncrow.de
Sat Aug 7 11:14:14 CDT 2010
Am 07.08.2010 14:06, schrieb Nikolay Sivov:
> On 8/7/2010 15:54, André Hentschel wrote:
>> Am 06.08.2010 20:44, schrieb Nikolay Sivov:
>>> On 8/6/2010 22:22, André Hentschel wrote:
>>>> got that case with an MFC application which had a 3state radiobutton
>>>> with buttonstyle 15(decimal)
>>>> with this fix everything is fine as the painting of the button is
>>>> handled elsewhere, without that fix it crashes as it reads bad data
>>>> behind the array.
>>>>
>>>> ---
>>>> dlls/user32/button.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/dlls/user32/button.c b/dlls/user32/button.c
>>>> index 54d54dc..4f629f0 100644
>>>> --- a/dlls/user32/button.c
>>>> +++ b/dlls/user32/button.c
>>>> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG
>>>> window_style )
>>>> /* paint a button of any type */
>>>> static inline void paint_button( HWND hwnd, LONG style, UINT
>>>> action )
>>>> {
>>>> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd))
>>>> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&&
>>>> IsWindowVisible(hwnd))
>>>> {
>>>> HDC hdc = GetDC( hwnd );
>>>> btnPaintFunc[style]( hwnd, hdc, action );
>>> This needs a test to see what happens visually for style 0xf, maybe we
>>> need just to duplicate an entry in paint function table; also while
>>> you're at it:
>>>
>>> static inline UINT get_button_type( LONG window_style )
>>> {
>>> return (window_style& 0x0f);
>>> }
>>>
>>> here BS_TYPEMASK should be used instead of 0xf.
>>>
>> Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i
>> made a typo in my oneline patch :)
>> But i am still not sure if we really should paint in that case
>> (unless some peoble come up with "invisible checkboxes"),
>> because in my case the dialog style was that "ms office 2007 style",
>> so mfc or the app handled the paint. if we would have drawn something
>> it would have make it worse.
> All I mean is that you need a small test app that creates button
> directly without any mfc wrappers or anything.
> Probably such style is even not accepted by control, or replaced with
> some other style.
>
> If style is not accepted or replaced this should go directly to button
> tests, if it's accepted we need visually guess how it works and add a
> handler.
i tested it on win7_x64 and it gets invisible after some dialog interaction, style gets accepted and is not replaced.
So my initial patch was mostly correct.
--
Best Regards, André Hentschel
More information about the wine-devel
mailing list