views:

617

answers:

3

i need to implement the functionality of EM_SETCUEBANNER, where a text hint appears inside an Edit control:

alt text

The catch is that i cannot use version 6 of the Common Controls, which is what is required to get the Microsoft supplied implementation of a cue banner.

i've looked into simply changing the text of the edit control, and the font format to

Dark Gray Italic Text

but it will throw Change events (component wrapper provided by higher component library) that i can't find a way to avoid.

So i was instead going to custom draw the text, drawing the Cue Banner text when the control is unfocused and empty, and rely on default painting otherwise.

The Edit control doesn't nicely expose a custom drawing mechanism, like ListView, TreeView and others provide.

Other people have looked into it, but it seems to be an nearly impossible task:

From the way things are looking, I'll have to handle the following messages:

  • WM_ERASEBKGND, WM_PAINT (for obvious reasons)
  • WM_SETFOCUS, WM_KILLFOCUS (to prevent the white bar from displaying -- described above)
  • WM_CHAR (to process and update the text in the control)

And I also need to find a way to display the caret in the control, since I haven't found a way to allow Windows to do that for me without also painting the white bar I mentioned.

This is going to be fun. :rolleyes:

Given that the Windows Edit control was never meant to be custom drawn: does anyone know how to custom draw a Windows Edit control?


Note: i will also accept answers that solve my problem, rather than answering my question. But anyone else wanting to custom draw an Edit control, coming across this question, would probably like an answer.

A: 

Subclass the edit control. Handle WM_PAINT by first calling the original window procedure and then, if it's empty and not in focus, draw the cue text. Pass every other message to the original window procedure.

I've done this--it works. The problem the CodeGuru person had doesn't seem to apply to your situation. I believe he's trying to do more to the appearance. For performance, it looks like the edit control is doing some updates outside of WM_PAINT processing (probably for performance). That's going to make it nearly impossible to take complete control of the appearance. But you CAN draw the cue prompt.

Adrian McCarthy
+1  A: 

Create a window class of your own that looks like and empty edit control, that draws the cue text and shows a caret and has focus. Create the edit control also, but position it behind your window. (or leave it hidden)

Then when you get the first WM_CHAR message (or WM_KEYDOWN?). You put your window behind the edit conrol, give focus to the edit, and pass the WM_CHAR message on. From then on the edit control will take over.

You can listen to EN_CHANGE notifications from the edit control if you need to go back to showing your cue text when the edit gets empty. But I'd think that it would be fine to go back to the cue text only when the edit looses focus AND is empty.

John Knoeller
+1  A: 

Custom drawing an Edit control is essentially impossible. There are a few specialized cases were you are doing so little that can get away with it, but you risk breaking badly in the next revision of windows (or when someone runs your app on an older version, or via terminal services, etc).

Just taking over WM_PAINT and WM_ERASEBKGROUND aren't good enough, because the control will sometimes paint on other messages as well.

You are better off just writing your own edit control. I know that's a huge amount of work, but in the long run it will be less work than trying to hack your way into taking over all of the Edit controls' drawing code.

I remember back in the good old days when everyone use to subclass the button control to add color and graphics, etc. The thing is, one day I sat down and just wrote my own button window class. and it was LESS CODE than what we had in our source tree to subclass and custom draw the Windows button.

John Knoeller
You seem to be right. i subclass the Edit, handling WM_PAINT if i want to draw the cue text. There are times (using mouse to select, pushing backspace in an empty edit) that the control paints itself as empty without calling WM_PAINT.On the other hand, there is a **LOT** of functionality that exists in an Edit, and i can no way justify all the investment in code. (cut/copy/paste, undo buffer, IME, RTL, etc)
Ian Boyd
Yes either way is going ot be a huge pile of code. I'm just saying don't fool yourself into thinking that subclassing with be less code. In the long run, it probably won't be.
John Knoeller
i ended up subclassing the edit, triggering a paint in response to the other messages, not just `WM_PAINT`. Some other messages that cause an internal paint to happen, without any `WM_PAINT` to happen, and require me to repaint over their repaint: `WM_SETFOCUS`, `WM_KILLFOCUS', `WM_KEYUP`, `WM_KEYDOWN`, and when the mouse enters and leaves.
Ian Boyd