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.
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.
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.
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.
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.
Ok i see.
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.
-
André Hentschel -
Nikolay Sivov