https://bugs.winehq.org/show_bug.cgi?id=40390
Bug ID: 40390 Summary: When using a UX theme, owner-drawn buttons don't draw until you click them once Product: Wine Version: 1.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs@winehq.org Reporter: ryampolsky@yahoo.com Distribution: ---
This may be a duplicate of 11521, but I'm not sure.
I have owner drawn buttons in my own app, and they work fine in WINE - unless I enable a theme in the 'desktop integration' settings. Then the buttons don't appear at all until I click them. Without a desktop theme, the buttons also redraw on mouse-over, but not with a theme. You have to actually click them, and then they show up - but they don't redraw on mouse over even then.
I think this used to work prior to version 1.8. Otherwise, I wouldn't have had theming enabled on this machine. It's an old Linux machine that I recently brought up to date - don't know what WINE version was on it previously.
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #1 from ryampolsky@yahoo.com --- I just determined that if I disable theming on the individual owner-draw buttons after I create them by calling SetWindowTheme(hWnd, L" ", L" "), owner drawn buttons work normally with a theme selected.
This seems to work consistently for pushbuttons that I create myself. But for pushbuttons defined with BS_OWNERDRAW on dialogs defined in my .rc file, it's inconsistent. For those, I tried adding calls to
SetWindowTheme(GetDlgItem(hDlg, <button_id>), L" ", L" ");
in my M_INITDIALOG handler. Works on some dialogs and not on others.
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #2 from ryampolsky@yahoo.com ---
SetWindowTheme(GetDlgItem(hDlg, <button_id>), L" ", L" ");
Just to be clear, the SetWindowTheme call to disable theming on owner-drawn buttons is not needed on Windows itself. The program runs fine on all versions of Windows I've tested it on, and my owner-drawn buttons work with mouse-over support, etc. But under WINE - I've tried it with the latest releases - on both Linux and MacOS, owner-drawn buttons only work if desktop theme integration is not configured or if I specifically disable theming on each owner-drawn button.
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #3 from ryampolsky@yahoo.com --- Just tried it with WINE 2.0. Still need to disable themeing on owner-drawn buttons for them to work, but ownerdraw buttons on dialogs are working more consistently now when I untheme them on WM_INITDIALOG.
https://bugs.winehq.org/show_bug.cgi?id=40390
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|uxtheme |-unknown
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- Could you attach your test application here?
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #5 from ryampolsky@yahoo.com --- The app doesn't do anything unless you have a server account to connect to - and I can't give you that.
I've mostly gotten around the problem by disabling theming on all my owner-drawn buttons. The one remaining problem with theming is that most themed controls (radiobuttons, checkboxes, scrollbars) draw unthemed when you click on them. Then then redraw themed again when they lose focus. I assume that's a known problem...
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- (In reply to ryampolsky from comment #5)
The app doesn't do anything unless you have a server account to connect to - and I can't give you that.
I've mostly gotten around the problem by disabling theming on all my owner-drawn buttons.
Obviously I don't need whole application, just a window with a single button that's handled in the same way you handle owner drawn buttons.
The one remaining problem with theming is that most themed controls (radiobuttons, checkboxes, scrollbars) draw unthemed when you click on them. Then then redraw themed again when they lose focus. I assume that's a known problem...
Yes, it's bug 37584.
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #7 from ryampolsky@yahoo.com --- I'll see if I can whip something up. May take a few days to get to it.
https://bugs.winehq.org/show_bug.cgi?id=40390
rebe@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rebe@gmx.net
--- Comment #8 from rebe@gmx.net --- Does the fix to bug 37584 also resolve this one in latest wine?
https://bugs.winehq.org/show_bug.cgi?id=40390
--- Comment #9 from ryampolsky@yahoo.com --- Yes. This is fixed in version 3.2. Thanks
https://bugs.winehq.org/show_bug.cgi?id=40390
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
--- Comment #10 from Nikolay Sivov bunglehead@gmail.com --- Duplicate.
*** This bug has been marked as a duplicate of bug 37584 ***
https://bugs.winehq.org/show_bug.cgi?id=40390
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Duplicates