edit box changes color

[user125]

I have created edit box, and placed it onto my main window, and everything works like it should; edit box appears on specified location, with white background, and black text. But when I include this edit box in my window proc like this:

SetWindowLong(edit_box_hwnd, GWL_WNDPROC, (LONG_PTR)myWindowProc);

edit box appears black, thus the text becomes invisible. I didn't process any messages to my edit box, inside the window proc, so the change of color has been done beyond my code.
Anyone experienced this behaviour ? And how to fix this?

[VictorN]

Why do you want to implement your own window procedure for this edit box? Is it some non-standard one?

[user125]

It is custom window proc for my main window's child windows. Newest of them is this edit box. This procedure existed before this edit box. Edit box is the last created control on my main window.

[VictorN]

But you don't "process any messages" to youredit box "inside the window proc". Then why do you set it for this control?

[2kaud]

What does myWindowProc() actually do? It could be helpful if you posted the code.

[user125]

But you don't "process any messages" to youredit box "inside the window proc". Then why do you set it for this control?

Great question. Actually, I want to write the WM_LBUTTONDOWN code for this edit box. But before I do that, I want to know why is my edit box black when I just use SetWindowLong.

[user125]

What does myWindowProc() actually do? It could be helpful if you posted the code.

myWindowProc mostly responds to mouse clicks on child controls. And it works fine.

[VictorN]

... But before I do that, I want to know why is my edit box black when I just use SetWindowLong.

I guess it is because your procedure does not handle WM_PAINT for edit box.

[user125]

I guess it is because your procedure does not handle WM_PAINT for edit box.

You 're right; It doesn't handle anything for edit box, yet. I've just set the procedure as it's window proc, and it changed color. I would like to know what I should do in WM_PAINT to restore my edit box to its default appearance.

[VictorN]

Try to call the default procedure for edit box.

[2kaud]

myWindowProc mostly responds to mouse clicks on child controls. And it works fine.

Probably not. That's why you have the issue. Within myWindowProc() for messages not handled (and for those handled but you also want to be handled by the control) you need to call the default procedure for the specific control using CallWindowProc(). This is the value returned from SetWindowLong(GWL_WNDPROC).

See https://msdn.microsoft.com/en-us/lib...lassing_window for an example.

[user125]

Probably not. That's why you have the issue. Within myWindowProc() for messages not handled (and for those handled but you also want to be handled by the control) you need to call the default procedure for the specific control using CallWindowProc(). This is the value returned from SetWindowLong(GWL_WNDPROC).

See https://msdn.microsoft.com/en-us/lib...lassing_window for an example.

Sorry, but I 've always had CallWindowProc() within myWindowProc. I have several completely functional controls handled by this procedure. Only this newest one, the edit box, have this unexpected behaviour. I probably have to write something in WM_PAINT or similar.

[OReubens]

the answer is pretty Obvious imo.
you have an error in your myWindowProc causing that effect.

likely becuase yuou only implemented the few messages you'r einterested in and none of the others
if you replace the messageprocedure, you're responsible to make sure ALL of the message get handled properly.
Either by handlign everything yourself, or by making sure you call the old handler for anything you don't.