Redrawing Over Lapping Windows

In my application, I have sibling windows (have the same parent), lets say I created wnd1 and then created wnd2. When I drag wnd2 on the top of wnd1, the components of the wnd1 are over ridding the component of wnd2.

I don't know what I have to do or how to prevent the lower window (i.e. wnd1 in our example) from over ridding the other window. Besides, I noticed that the window created first, always have the priority on the window created later.

There is something wrong in my code but don't know where.

Below is a piece of the code that creates 3 windows (main and 2 children windows).
In order to know the exact flow of the code, see below notes:
- Main Window, takes formFlg_p = 0. It is the parent of the other both windows.
- Window 1, takes formFlg_p = 1
- Window 2, takes formFlg_p = 2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

 .
 .
 .

void BsolWindow::BsolCreateWindowEx (BsolWindow * prntWnd_p, int formFlg_p, int wndId_p, LPCWSTR wndTitle_p, 
				 int x_p, int y_p, int width_p, int hight_p, LPVOID objPtr_p) {
wExStyle_v = WS_EX_APPWINDOW;

if (formFlg_p == 0) {
	wStyle_v = WS_CLIPCHILDREN 
		 | WS_OVERLAPPEDWINDOW 
		 | WS_VSCROLL
		 ;
}
// The window is a form window (child window)
else {
	// Set the parent window
	phWnd_v = prntWnd_p->hWnd;

	if (formFlg_p == 1) {
		wStyle_v = WS_CHILDWINDOW 
			 | WS_TILEDWINDOW 
			 | WS_OVERLAPPED 
			 ;
	}
	else if (formFlg_p == 2) {
		wStyle_v = WS_CHILDWINDOW 
			 | WS_OVERLAPPED 
			 | WS_SYSMENU 
			 | WS_CAPTION 
			 | WS_SIZEBOX 
			 ;
	}
}

this->hWnd = CreateWindowEx (wExStyle_v, this->wndClass.lpszClassName, 
				wndTitle_p, wStyle_v, x_p, y_p, width_p, hight_p, 
				phWnd_v, (HMENU)wndId_p, this->hInst, NULL);
 .
 .
 .


I'll be waiting your advices and help.

Regards,
Ahmad
A window can only be WS_OVERLAPPED or WS_CHILDWINDOW (same as WS_CHILD) or WS_POPUP. You cannot mix these.

If you want to be able to drag any child window in front of all the others, then you will probably have to adjust the z-order. Check out SetWindowPos and BringWindowToTop for how to do this.

SetWindowPos function
http://msdn.microsoft.com/en-us/library/aa931583.aspx

BringWindowToTop function
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632673%28v=vs.85%29.aspx

Andy

PS If you check winuser.h you'll see that

1
2
3
#define WS_OVERLAPPED       0x00000000L
#define WS_POPUP            0x80000000L
#define WS_CHILD            0x40000000L 


so it's impossible to define WS_OVERLAPPED at the same time as WS_POPUP or WS_CHILD. And it is illegal to specify WS_POPUP and WS_CHILD simultaneously.

Also

1
2
3
4
5
6
7
8
9
10
#define WS_TILEDWINDOW      WS_OVERLAPPEDWINDOW

#define WS_OVERLAPPEDWINDOW (WS_OVERLAPPED     | \
                             WS_CAPTION        | \
                             WS_SYSMENU        | \
                             WS_THICKFRAME     | \
                             WS_MINIMIZEBOX    | \
                             WS_MAXIMIZEBOX)

#define WS_CHILDWINDOW      (WS_CHILD) 


so

1
2
3
			   WS_CHILDWINDOW 
			 | WS_TILEDWINDOW 
			 | WS_OVERLAPPED 


is the same as

1
2
3
4
5
6
                             WS_CHILD          | \
                             WS_CAPTION        | \
                             WS_SYSMENU        | \
                             WS_THICKFRAME     | \
                             WS_MINIMIZEBOX    | \
                             WS_MAXIMIZEBOX)


and I'm not sure all these flags mean anything to a child window.

Andy


Last edited on
I adjusted the style to be:
1
2
3
4
5
6
                             WS_CHILD          | 
                             WS_CAPTION        | 
                             WS_SYSMENU        | 
                             WS_THICKFRAME     | 
                             WS_MINIMIZEBOX    | 
                             WS_MAXIMIZEBOX)


However, each one of those bits are reflected perfectly to the child window. I tested them after your notation.

Regarding BringWindowToTop, I tried it and it worked but I am still facing problems. The 2 windows are still over-ridding each others.

In this regards, after I moved wnd2 to top of z-order, I pressed on the wnd1 (window not on the top of z-order) and I noticed the below:
1- The window does not become activated although the window procedure is processing the messages
2- I press on the control (Edit for example) in wnd1, the focus is set and cursor is set to that edit control, but still the window is not activated and not moved to front.

There is something wrong in processing the messages because the DefaultProcedure of the windows and controls are not working properly.

For sure, there is a way that when a window is activated, it will:
1- moved to top of z-order (over rid all other windows)
2- gain focus
3- get the cursor

Sorry for the mess in my update and thanks in advance for your support.
Regards,
Ahmad
I am rather unclear about that you want to achieve. But I am now wondering if you might need to use the MDI mechanism?

Multiple Document Interface
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632591%28v=vs.85%29.aspx

Andy
Thanks for your suggestion.. I went through MDI but I am not sure if this what I need.
I'll summarize for you what I am trying to do:

I am developing an bank application where the user will start with a Login and then he might open several screens (forms) each of which contains several controls (Edit, Buttons, Text Box, List View, ...) and he might open List of Values popups or another Form from the current form by pressing a buttons.

This application will be communicating with a database (I think SQL server) where it will insert and retrieve data.

Now I am preparing the functions and procedures that will establish all types of communication between the Forms GUI and the database.
On the other hand, I am still preparing the behavior of the GUI where the application must be able to manage several forms opened simultaneously. I am doing fine so far but I am facing the issue of activating, moving, overlapping, sizing windows and its components.

I don't know if I need MDI or not, but as I noticed, MDI is for creating typing documents (like word or pad or even Microsoft Visual studio that I am using). Please correct me if I am wrong and let me know you suggestion in regards of all above.

Thanks in advance.
Best Regards,
Ahmad
The MDI mechanism is a way of handling child windows. What the child windows do is totally up to you; it's not just for Word-like documents.

What you want to do with you child windows (activating, moving, etc) does sound like the kind of thing MDI is designed to handle.

Andy
Andy..

I tried to switch my code to handle the MDI mechanism, however, I need to change the messages handling and naming. As well as I prefer not to move to MDI mechanism since it is a new subject for me. So I decided to stick to the current mechanism.

Anyway, I debugged the handling of the WM_LBUTTONDOWN message where I am calling BringWindowToTop macro, I found that the window is moved to the top of z-order (I check the z-order by calling GetNextWindow macro). However, neither the window nor its client area and its controls (children) are been repainted or redrawn.
My question, is it correct to invalidate the window to have it redrawn or the OS must invalidate it since the window is moving from behind another window to the top?

Please let me know if I am not clear enough and thanks in advance for your suggestions.

Best Regards,
Ahmad

is it correct to invalidate the window to have it redrawn

It's fine to invalidate the window's rect.

(Actually, it might be one of the cases where UpdateWindow is appropriate. But I would see how well behaved the InvalidateRect approach was first.)

Andy
Last edited on
Andy..
Thanks for your help and support.
The issue is resolved. The problem was in the style of the window. It worked properly when I specified WS_CLIPSIBLINGS.

It is working perfectly now.

Thanks again.
Ahmad
Topic archived. No new replies allowed.