0

I have a window with several controls on it, but only the edit control is ignoring the visual styles. I've tried to track down the cause but have had no luck so far. Here is what it looks like:

Edit control has old 3D style

As seen, the button and the listbox controls have the proper visual style. The edit control, however, does not. I had the proper style applied once a few days ago after changing a bunch of code unrelated to it so I know it's possible.

Things to note:

  • I have tried calls to InitCommonControls and InitCommonControlsEx with no success.
  • I have the WS_EX_CLIENTEDGE applied to the edit control and have always had that extended style turned on, even when it was working prior.

I have included as much code as I can to help track down this issue.

From my TextBox class (which inherits Component):

protected:

virtual void OnRegistering(CreationParameters& createParams)
{
    // this is passed in as the lpClassName parameter in 
    // CreateWindowEx() and the lpszClassName parameter in WNDCLASSEX
    createParams.BaseClassName = WC_EDIT;

    // passed as the dwStyle parameter in CreateWindowEx()
    createParams.WindowStyles |= ES_AUTOHSCROLL | ES_AUTOVSCROLL; 

    // passed as the dwExStyle parameter in CreateWindowEx()
    createParams.WindowExStyles |= WS_EX_CLIENTEDGE;
}

Would an issue with handling the WM_CTLCOLOREDIT or WM_ERASEBKGND messages have anything to do with this? Or an issue with handling fonts? Or something else? Because I am 100% out of ideas at this point.

jvstech
  • 844
  • 1
  • 9
  • 28
  • Try removing the line containing WS_EX_CLIENTEDGE in your code and see if it helps. – mfc Feb 24 '13 at 02:13
  • @mfc: I did that and all it did was remove the border entirely. WS_EX_STATICEDGE was a bit closer to what I was looking for, but I actually ended up solving the problem myself. – jvstech Feb 24 '13 at 02:52
  • If the problem is only having no border, you may be able to add it by adding WS_BORDER to the WindowStyles. – mfc Feb 24 '13 at 03:56

1 Answers1

4

The issue was that the HBRUSH I was using to color the edit control was, somehow, inexplicably never initialized and was NULL. Since I know other people were having issues with this, here is my solution.

The problem manifested itself when WM_CTLCOLOREDIT arrived in the message queue. If an improper/incorrect HBRUSH is returned when that message arrives, the edit control reverts back to old visual styles. Since my HBRUSH was NULL, the old visual style was applied to the edit control.

jvstech
  • 844
  • 1
  • 9
  • 28
  • I, too, was returning FALSE for edit that should not be colored, instead I should've been returning control to DefWindowProc. Thanks, dude, saved me some time ;) – Kitet Jun 20 '15 at 11:12