Hey all =)

This one might be a little sticky, maybe not. I guess I will see heh.

Well as always, I am coding another custom control and thought this time I would take a stab at a highlighter. Completely custom. Its about done but I was curious as to one point (which at the time of this writing is moot).

I basically have a subclassed window and draw directly to it through an off-screen dc to eliminate flicker and all is well. However, I can draw a cursor anywhere I please but of course Windows has no idea it is *supposed* to be a cursor. So if I happen to pop down a normal edit control right next to it, it *hogs* all the key messages and my window never sees it. Is there some "magical" process to register a window as being able to have cursor focus?

* note to curious *
I got around it by creating an invisible 1x1 MLE and use it to capture all the key input to my window which neatly gets around the problem.

But it made me very curious as to how it should be coded properly without using a system carot...
Posted on 2002-05-15 09:28:16 by Graebel
SetFocus() maybe?
Posted on 2002-05-15 09:55:55 by AmkG
Originally posted by Graebel
So if I happen to pop down a normal edit control right next to it, it *hogs* all the key messages and my window never sees it.

No offense, but this doesnt explain the events very well :confused: . By Poped do you mean with the mouse, with the tab key? What? Did you start by being able to write on your control, and then cant get back??

Little more help please? ;) But gut feeling says its probabaly in the way you subclassed the window, and voided a message you shouldnt have.

PS: I will have my custom tut finished hopefully today, if i muster some more energy for it ;)

Posted on 2002-05-15 12:59:22 by NaN
Well ok, let me explain this a little clearer.

There is more than one kind of focus. You can have window focus and cursor focus. Say you have two windows each with two edit controls.

If window one has focus, either edit1 or edit2 of that window will have cursor focus (the blinking carrot). If the second window has focus, either edit3 or edit4 will have cursor focus.

Now I created a custom control which does *not* contain a system carrot. I draw it manually. If I place this control into a window with an edit control the cursor focus will continue to stay with the edit control and all key messages will be routed there. Makes since because it is the only control with a system carrot.

The question revolves around is if there is a way to tell Windows that my window can not only get focus, but cursor focus as well. Or at least steal it from all the other controls...
Posted on 2002-05-15 13:23:50 by Graebel
Im with AmkG here,
The SetFocus function sets the keyboard focus to the specified window. All subsequent keyboard input is directed to this window. The window, if any, that previously had the keyboard focus loses it.

HWND SetFocus(

HWND hwnd // handle of window to receive focus

The normal edit window shouldnt be hogging the focus from other windows by default.

And i disagree with the fact that the focus is dependant of where the 'caret' is. The caret api's will not be displayed if a window doesn not have focus, this is true, but it doesnt imply that a window with a caret HOLD focus by default. This is some other mechanism being done by the normal edit window. Which is why i think that your overlooking a message when you subclass your edit control. Do you handle "WM_SETFOCUS" and "WM_KILLFOCUS"??

Posted on 2002-05-15 14:01:40 by NaN
Interesting quote. I just added an MLE to the Multi-Win icz Tut and it was as I thought. The child window2 will not steal focus from the MLE no matter how many times you click it. That quote only applies to top level parent windows. Not children.

Oops, maybe I am creating the confusion... I thought it would be understood since I said it was a control that it would be a child of some other window... my bad.

Maybe now since we are all straight someone might know the answer?

Thanks for the patience :alright:
Posted on 2002-05-15 14:25:37 by Graebel
Your right about this, i noticed this too before, but i simply forward on the focus message to my edit control.

However, i see how this compicates your problem. I cant say i have an answer why the windows edit control will get focus first from a window, as a child.

My gut feeling here is that windows is registering the edit control somehow as a fist forcus window. Maybe something to do with tab stops?? Dunno really. If so, it must be handled by the DefWindowProc handler. Try handling the WM_SETFOCUS message in the parent window, and do nothing, other than let the handler know you've taken care of it (xor eax, eax), and see if this trend stops. If so, then you know you got to sniff out a new api to register you window too.

This is my best guess, but i have a hunch i will hit this wall soon, with my custom edit control. Right now im testing with one instance, so i havent seen this case yet... :rolleyes:

Posted on 2002-05-15 14:47:38 by NaN
I don't know the answer, but maybe it can be found here:
Posted on 2002-05-15 15:05:05 by bitRAKE