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