http://bugs.winehq.org/show_bug.cgi?id=27920
Summary: ComboBoxEx doesn't process WM_ENABLE properly Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: lightning_uk@imgburn.com
Created an attachment (id=35721) --> (http://bugs.winehq.org/attachment.cgi?id=35721) Test / Demo App
Unlike ComboBox, ComboBoxEx doesn't appear to process WM_ENABLE properly.
Its 'look' never changes from the initial one - be that enabled or disabled.
So if it's disabled when created, it'll stay looking disabled even after you've enabled it. If it's enabled when created, it'll stay looking enabled even after you've disabled it.
If disabled when created, you can't interact with it (get it to drop down etc) even when you've supposedly enabled it.
The above can be fixed by handling WM_ENABLE in COMBOEX_WindowProc.
Something like the following does the trick (idea taken from combo.c)...
case WM_ENABLE: if( infoPtr->hwndEdit ) EnableWindow( infoPtr->hwndEdit, (BOOL)wParam ); EnableWindow( infoPtr->hwndCombo, (BOOL)wParam );
/* Force the control to repaint when the enabled state changes. */ InvalidateRect(infoPtr->hwndSelf, NULL, TRUE); return TRUE;
Once that has been added, you see another problem with the control...
When disabled, it doesn't draw the contents of the combobox - compared to Windows (Vista/7 anyway), that's wrong.
Windows greys the control (drop down arrow etc) out but the image+text remain visible and 'normal' colour.
That can be fixed by commenting out the following line in COMBOEX_DrawItem
if (!IsWindowEnabled(infoPtr->hwndCombo)) return 0;
I've added a demo app attachment that shows the problem with ComboBoxEx. You should notice that if you press the 'Enable' button before the 'Show' button, the ComboBoxEx control looks and behaves differently to if you press 'Show' and then 'Enable'.
There's a traditional ComboBox on the form too just for comparison.