Child Window and Input Priority

I'm having trouble with my child windows, when they overlap then the window that was opened first is getting the mouse input.
The way I understand SetFocus is that it only sets the keyboard input, so what can I do to make sure the window on top gets all the right messages?

or am I creating the window wrong;
	//this is in my ParentWndProc;
		case ID_STUFF_NEW:// create child window from Menu input
			hWnd[gamecount] = CreateWindow (szAppName, NULL,
			400, 400, hwnd, (HMENU) gamecount,(HINSTANCE) GetWindowLongPtr(hwnd, GWLP_HINSTANCE), NULL) ;
			gamecount ++;

would I be able to get the mouse input from the parent window and use getfocus to then send the info to the right window? I'll work on setting that up but if that's not the best or simplest way then please give me a hint, thanks.
Last edited on
I have to say newbieg, I've never created a window with the WS_OVERLAPPEDWINDOW | WS_CHILDWINDOW style. In my mind, they are mutually exclusive styles, but I could be wrong. Since WS_OVERLAPPEDWINDOW windows are more in the style of top level windows, they have title bars, so on and so forth. Child windows, on the other hand, don't usually have those things, and behave differently.
It's a ticTacToe game that let's the user open multiple games (The WS_OVERLAPPED is so they have the exit, resize, minimize and maximize options, etc.). Right now It's only 600 lines of code but I'm adding to it as I learn anything new from Petzold's 5th.

The project is for practice and so that I have something to look back on later in case I forget how to code something. This Bug has been on my nerves since I started and up to now I've just tried to ignore it.

You know, you're right Freddie1, If I took out that OVERLAPPED option I would have to figure out how to create those options from scratch and can make my own style while doing it. That's going to be my next change, but I want to focus on the bug first.
Last edited on
Only your parent window should have the WS_OVERLAPPEDWINDOW style, your child window shouldn't.

You either create a second different flying window with the WS_OVERLAPPEDWINDOW style, or you make a in-window child window (like a edit control) with the WS_CHILDWINDOW style.
Last edited on
Yikes, didn't mean to make that an issue or anything. I don't see a problem with WS_OVERLAPPEDWINDOW in my child windows since I like having overlapped windows that are confined within the parent's client area. The problem I was having had to do with the "Z Level" of the window, the quick fix turned out to be this code in my child windowProc;
SetWindowPos(hWnd, HWND_TOP,//set window to top of Z level stack

and also to Invalidate the entire child window rect. There were also a couple other tweaks I had to make to my code and it's still not perfect.

I do plan to eventually get rid of the WS_OVERLAPPEDWINDOW, but for right now it is good practice trying to work out the bugs it causes.
Last edited on
Well that's kinda weird but... As long as it works.
Topic archived. No new replies allowed.