0

I am in the process of writing a super classed version of the Windows LISTBOX common-control to add extra functionality.

A standard control sends the WM_CTLCOLORLISTBOX message to its parent which allows both its text and background colours to be specified at run time within an appropriate message handler. However WM_CTLCOLORLISTBOX is not sent to the control itself, therefore cannot be encapsulated and handled internally.

The scenario I am attempting to address is to change the background and text colours depending on the control's enabled/disabled state. The standard behaviour of leaving the listbox background the same shade regardless of its state looks ugly and inconsistent to me. Is there another way to set these values within the encapsulation, yet hand-off all other painting tasks to the base-class window procedure?

I wondered about using SetClassLongPtr(). However, not only would this not address the text colour but if I understand rightly it would change the background for ALL controls of that class currently in existence and not the specific control whose state has changed.

1 Answers1

0

The answer should be obvious - since WM_CTLCOLORLISTBOX is sent to the parent window, you have to subclass the parent window in order to receive the message. There is no getting around that. However, some wrapper UI frameworks, like VCL, are designed to forward such messages to the control that generated then, so controls can handle their own messages. But if you are not using a wrapper framework and are working with Win32 directly, you have to handle the parent messages yourself. Refer to MSDN for details about subclassing a given HWND:

Subclassing Controls

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Actually it was obvious @Remy! Set the customized control as a child _inside_ another - invisible - child window of the same size and position then handle WM_CTLCOLORLISTBOX in **its** window procedure. This compromize consumes extra resources, but I am willing to live with it. –  Dec 08 '14 at 03:49