The window has many attributes, which can be known by setting the style and ex style of the window.
These attributes are sometimes very important when implementing certain effects (I didn't know much about them in detail before, but I did not go into detail when using the corresponding API ).
Here, I want to record the problems encountered in my recent work. It is about window hierarchies, the relations between them, and the window control experience.
First, you need to know the difference between parent and owner:
1. If a window has the ws_child attribute, it must have a parent window, that is, getparent () must return itsParent window;
2. If a window has the ws_child attribute, it cannot be a popup/overlap (the two attributes are included in the createwindow, or are set using getwindowlong/setwindowlong and gwl_style) window;
3. Top-level window refers to the window at the bottom layer of the desktop. It can only be a popup/overlap window;
4. The popup/overlap window is the top-level window. Generally, the popup window is the normal dialog window we see, overlap windows are the single document windows that we directly create using MFC;
5,The owner window can onlyIs the top-level window, And the owned window is also the top-level window;
6. The getparent () function returns the parent of the corresponding window,Or the owner window;
7. getwindow (hwnd, gw_owner) Only returns the owner window; otherwise, it is null;
8. To obtain the real parent window, the logic should be as follows: uint style = getwindowlong (hwnd, gwl_style); Return Style & ws_child? Getparent (hwnd): getwindow (hwnd, gw_owner );
Since the following article is very well written, I have come to the conclusion below:
Http://www.laho.gov.cn/cjs_new/print.jsp? Oldid = 34
This blog also provides a detailed description of the window attributes. I have also referred to some of them:
Http://www.cppblog.com/Clouderman/default.html? Page = 2
The following is what needs to be viewed on msdn:
Http://msdn.microsoft.com/en-us/library/ms632599%28v=VS.85%29.aspx
Msdn seems to be the most authoritative, but the content mentioned in the above article and the experiment in it are worth reading. After reading the above, it will be more practical.
There are three options for hanging a window in front of a d3d rendering window:
1. Create owner/owned window
The owned window must be in front of the owned window, so this method works. Window Mechanism to ensure:
1) After rendering the owner window, render the owned window;
2) When the owner window is minimized, the owned window is also minimized;
3) when the owner window is restored, the owned window is also restored together;
If you view the layers of the owner and owned windows in spy ++, you will find that they are on the same layer. The relationship between the owner and owned windows is not strong in the relationship between the parent and child windows! (For details, refer to the above link, which provides a clearer description ).
The owner/owned window has a condition that the owner/owned window must be a top-level window. This leads to a problem: what if my d3d window is a subwindow of a window? At this time, the problem will easily occur. Because the rendered d3d window itself is a child window, it is very easy to receive the influence of the parent window, And the owned window you created, it is controlled by the parent window of the rendering window. Because you usually have handle of the rendering window, sometimes the operations made by the owner window are not what you want! This is troublesome. You need to detect a variety of messages to avoid situations that you don't want to appear.
PS: the SDK method for creating the owner/owned window is createwindow ("mywinclass", "title ",
Ws_popup,
X, Y, W, H,
Hownerwnd, Null, hinst, null); ws_popup and hownerwnd must be entered here. ws_popup can be the ws_overlapped attribute (because a top-level window can be created)
2. parent/child relationship window
In fact, we can regard owner/owned as a weak parent/child relationship. As described above, both parent and child have them. However, parent does not need to be top-level. Therefore, your child must be bound to the parent and displayed in front of the parent window. This is exactly what we want. However, when parent is invalid, it will send a repaint message to the child, because it is a d3d window (usually rendered once at 30 frames, resulting in window invalid ), therefore, the Child Window will inevitably receive the repaint message without interruption, but the problem may flash.
Ms has already thought of this situation, so it provides a ws_clipchileleattribute to set the parent window. In this way, when parent is in invalid, messages will not be sent continuously.
You must also note that the rendering of the Child Window must be managed by yourself. If you refresh the window when you are dependent on the invalid of the parent window, sorry, there must be a bug.
3. Top-most window
This can be set at setwindowpos. The difference is usually used in full screen mode, but it is rarely used in other cases.