The WinAPI docs state:
A child window is grouped with its parent in z-order.
Two questions:
What does "grouped" mean in this context?
How is the z-order of siblings determined?
I'm trying to understand the precise z-order / draw order of a complex hierarchy of windows under a single top-level window for the purposes of doing blended rendering via D3D / DirectComposition of child windows onto parent windows.
Related
I want to build and editor, similar to many 3d editors out there, that has an opengl viewport somewhere in the window, and the rest of the window contains Windows controls. How do I do that? So far I managed to create a window that opengl renders to all of its area.
Although it is better to avoid rendering to the OpenGL window except via OpenGL, the controls are child windows in their own right, so there should be no problem simply rendering to part of the parent window (glViewPort can help with that). Windows will take care of drawing the controls "on top of" the parent window. Alternatively, you can create a child window of your own and attach the OpenGL context to the child window. Then you can render to the whole of the child window.
What I'm trying to do is very simple but there doesn’t seem to be a lot of information on it. Basically I have a normal non-transparent parent window and I want to place a child window (that has its own non-transparent controls) inside that parent window. So the only thing I have to do is to set the background brush of the child window transparent, but it still draws a white background. Tried using WS_EX_LAYERED style and SetLayeredWindowAttributes but it makes the child window invisible.
There are two basic ways to achieve "transparent" child controls on Windows:
Handle WM_CTLCOLORxxx messages in the parent window.
This is a convenient way to make existing controls support transparency. Each control will send a WM_CTLCOLORxxx message appropriate to the type of the control. If you create a brush that represents the background skin of the dialog, and return that from each message, the net effect will be as if each control was painted with a transparent outer area.
This fails however if you want alpha effects, or for controls to physically overlap each other.
Use WS_EX_COMPOSITED on the parent window.
Without this style, the window managers paint order of child windows is undefined, in practice, its top to bottom. When trying to alpha blend overlapping controls the result will be... unpleasant. WS_EX_COMPOSITED will ensure the child windows are painted bottom to top. Make sure that you DON'T use either the WS_CLIPCHILDREN or WS_CLIPSIBLINGS styles as that will prevent the overlapping areas from being painted at all.
You still need to do something clever via WM_CTLCOLORxxx messages as the standard controls are still going to try and fill their entire rect with dialog-background-grey.
How do you make the button with overrided WM_PAINT transparent. So that you could see the form through it in all places except where something is drawn. At the same time avoiding the flicker.
I saw examples with SetBkMode(HDC, TRANSPARENT), using NULL_BRUSH, examples with CompatibleDC and BitBlts, but I'm not quite sure which is the correct way to go, and also, how it behaves when WM_CLIPCHILDREN is set on the parent window. Most of the experiments I did had some weird behavior as well. Can't find a good documentation on WM_ERASEBKGND/WM_CTLCOLOR/WM_PAINT/WS_EX_COMPOSITED/WS_CLIPCHILDREN/etc internal relations on MSDN at all.
Does anyone know where I could read about this topic with all the gotchas associated?
mmm, I've never found anything close to a authoritative document on this topic.
This just serves as my rather random memory dump trying to get controls to "play nice", when animated, on a window that was either skinned (normal non client area with a bitmap background), layered (to get a window with custom non client edges with drop shadow effects) or with extended Aero Glass (via the DwmExtendFrameIntoClient) effects.
SetBKMode(... TRANSPARENT) just ensures that text rendering does not fill in the background of the text with the current bk color.
WS_EX_COMPOSITED causes windows to paint the parent and all child windows to a back buffer when the parent is invalidated, and then paint the back buffer. This is flicker free, but NT 6.0 introduced the desktop window manager which does not honor WS_EX_COMPOSITED.
WS_CLIPCHILDREN prevents the child windows and the parent window painting the same area twice. But is contra indicated if you need to use group boxes, or tab controls.
WS_CLIPSIBLINGs could be useful if child windows overlap and cause flicker. again this style is useless if you need to use group boxes or tab controls.
The other problem with WS_CLIPCHILDREN is you can't paint a background in the parent widnows window proc and rely on a NULL brush to reveal the skin. You can return a brush from WM_CTLCOLORxxx messages to coerce some of the standard controls to paint their background with your skin bitmap.
WS_EX_LAYERED is another style that makes windows buffer the painting of your parent window. But the layered windows painter does not paint child windows at all, so you need to manually paint the child windows by sending WM_PRINTCLIENT messages. Not all controls support this message.
WPF gets around the lack of back buffered painting and alpha support by not creating actual child windows at all for its buttons.
Final take on the situation:
With a little work you can get a skin behind most standard controls easily. WS_CLIPCHILDREN and no background painting on the parent will mimimize flicker. Handle WM_CTLCOLORxxx to fill the background on the controls.
If you are using Group Boxes or TabControls to frame other controls you absolutely must get the Z-order correct if using WS_CLIPSIBLINGS.
By sending controls WM_PRINTCLIENT messages, and some subclassing, you can get standard controls to paint onto a DIBSection, which you can then manually (or use DWM worker functions) repair the alpha channel of, and then paint onto a layered window, or a window with extended aero glass. This is even flicker free, but controls that don't support WM_PRINTCLIENT, or frequently update themselves outside of WM_PAINT, will not display correctly.
We place our transparent app window, over the window of another process. Our window contains some child controls. We create a WS_EX_LAYERED window, using colorkey for selective transparency. The main window is completely transparent, so it only functions as a container for the child controls.
This works fine on XP and Vista without Aero. However, on Vista with Aero clicks do not pass through the transparent area. What can we do?
Using WS_EX_TRANSPARENT fails, it makes our own controls inoperable, of course.
I have considered hiding the parent window (WS_SHOWWINDOW), but I am fairly certain that that will hide all children, and AFAIK resizing the window to a minimal size, with any combination of CLIPCHILDREN & CLIPSIBLINGS would fail in a similar way...
Thanks for any help.
Another option is to use a window region and not WS_EX_LAYERED
WS_EX_LAYERED is what handles graphical Window Transparency, click-through is merely a side-effect that happened to work on older Windows OSes.
WS_EX_TRANSPARENT is what makes the mouse transparent. Graphical transparency is not assured with this flag. You must manually draw the controls (using GDI functions) (like in a directX application) and catch the cursor position using a low level hook.
First, I'm working on Win32 with C++.
I have been trying to implement a transparent window with a child window which should remain 100% opaque. It seems that child controls cannot have opacity better(lower) than the parent and if I make my parent 100% transparent then my child control also inherits the transparency.
Code that I use -
SetLayeredWindowAttributes(GetParent(parentWindowHwnd), 0, 0, LWA_COLORKEY, LWA_ALPHA);
Any help?
Please also reply if I am not very clear with my question.
You can't do this unfortunately, child windows always have the same opacity as their parent. The Google Desktop Toolbar had a neat trick to give the illusion of an opaque textbox on a translucent background. They created two top level windows, one of the background and one for the textbox. Then they set the background window as the owner (not the parent) of the texbox. They then set the background as transparent. It's quite a bit of work to get right, but it's the only way to do it without rendering the whole thing yourself using UpdateLayeredWindow.
I'm certain you can do it the other way round, i.e. an opaque main window with a transparent child window, so the reverse may also be true. Have you tried unsetting the WS_EX_LAYERED flag for the child window and then redrawing it to make it completely opaque again?
// Remove WS_EX_LAYERED from the window styles
SetWindowLong(hChildWnd,
GWL_EXSTYLE,
GetWindowLong(hChildWnd, GWL_EXSTYLE) & ~WS_EX_LAYERED);
RedrawWindow(hChildWnd,
NULL,
NULL,
RDW_ERASE | RDW_INVALIDATE | RDW_FRAME | RDW_ALLCHILDREN);
The MSDN page on Layered Windows may also help.
You cannot make a child control less transparent than its parent. The usual approach here is to give your window an irregular shape: not a rectangle. This is much older that alpha transparency - Think about a clock application: you can make your window circular if you wanted, even on windows 95.
This could be done using the Windows API function SetWindowRgn:
A simple (vb) example
Google results