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.
Related
I have an app that creates 1 or more windows. These windows are Direct3D contexts, in which I do rendering.
When Windows has hardware acceleration turned on for the desktop (Aero), everything renders fine. I can move the window around without issue.
If I switch the Windows theme to Windows Basic, it's a disaster. The window renders properly, but if I drag the window around, it leaves a trail of the image behind it. Think of winning at Solitaire.
Any ideas what might be causing this. It's fine otherwise, but it seems to just draw all over everything as it's moved around.
The DirectX renderer is very simple. Clear, Select Texture, Select Vertex Buffer, Select Index Buffer, Draw.
Update
The window hierarchy for each window is as follows:
Parent Window, WS_EX_LAYERED and WS_POPUP. GDI+ draws a frame around the window.
Child Window, WS_EX_TOOLCHAIN and WS_POPUP | WS_CLIPSIBLINGS | WS_CLIPCHILDREN. DirectX draws into the child.
From what I've determined, if you aren't in a compositing mode, moving a DirectX window will do this. A lot of examples have the rendering code in the main loop, which means the PeakMessage hangs the renderer.
The solution is, before any MoveWindow call, detect whether compositing is enabled, via system version checking and DwmIsCompositionEnabled. If we can't composite, snapshot the rendered window, hide the DirectX window and draw the snapshot. Once movement is done, turn rendering back on.
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.
Looking at a Windows tooltips class hint window, i see that it draws its drop-shadow outside the hint window's actual rectangle.
Using SpyXX - i can get the tooltip's window rect, and class styles:
Rectangle: (440, 229)-(544, 249), 104x20
Restored Rect: (440, 229)-(544, 249), 104x20
Client Rect: (0, 0)-(104, 20), 104x20
You'll notice that the drop shadow you see is physically outside the window that's being drawn. How can i draw a shadow outside around my window, while being outside my window?
Note: The shadow is not drawn using the standard CS_DROPSHADOW class style. i've confirmed this experimentally, and can also see the class style's for the window in SpyXX; it does not use CS_DROPSHADOW:
Windows Styles: 94000001
WS_POPUP 80000000
WS_VISIBLE 10000000
WS_CLIPSIBLINGS 4000000
TTS_ALWAYSTIP 1
Extended Styles: 00080088
WS_EX_LAYERED 80000
WS_EX_TOOLWIN 80
WS_EX_TOPMOST 8
So how can i draw outside my window?
Note: Trying to draw on the desktop DC is out. From Greg Schechter's Redirecting GDI, DirectX, and WPF applications:
Drawing To and Reading From the Screen
-- Baaaad!
Lastly, since we're on the redirection
topic, one particularly dangerous
practice is writing to the screen,
either through the use of GetDC(NULL)
and writing to that, or attempting to
do XOR rubber-band lines, etc. There
are two big reasons that writing to
the screen is bad:
It's expensive... writing to the
screen itself isn't expensive, but it
is almost always accompanied by
reading from the screen because one
typically does read-modify-write
operations like XOR when writing to
the screen. Reading from the video
memory surface is very expensive,
requires synchronization with the DWM,
and stalls the entire GPU pipe, as
well as the DWM application pipe.
It's unpredictable... if you somehow
manage to get to the actual primary
and write to it, there can be no
predictability as to how long what you
wrote to the primary will remain on
screen. Since the UCE doesn't know
about it, it may get cleared in the
next frame refresh, or it may persist
for a very long time, depending on
what else needs to be updated on the
screen. (We really don't allow direct
writing to the primary anyhow, for
that very reason... if you try to
access the DirectDraw primary, for
instance, the DWM will turn off until
the accessing application exits)
You can't draw outside your window in the manner you describe.
If you right click your desktop then go to properties/appearance/effects and uncheck 'Show shadows under menus' ... you will no longer have the shadow.
Bottom line is that this is a product of the window manager not your program.
Q: How do you draw outside of one window? A: Draw inside another window!
First thing to note is that the tooltip class actually does use the CS_DROPSHADOW style - but note that this is a class style, not a window style, so you have to look at the Class tab in the Spy++ properties dialog to find it. You'll see that the tooltips_class32 windows does indeed have this - and a few others.
But that just leads to the next question - how does that work? Well, it seems that Windows implements this by creating a helper HWND to draw the shadow - presumably it's creating another popup window the same size and shape as the one it's shadowing, filling it with gray, placing it directly underneath the main window, and setting it as a WS_EX_LAYERED window so that the shadow can be transparent and fade out around the edges using alpha-blending. And there's nothing to stop you from using the same or similar techniques yourself if you want to add a different type of shadow effect to one of your own windows.
So, long story short: if you want to draw outside of your own window, create a helper transparent window in the general area that you want to draw on, and draw on that helper window instead.
--
Now, if you try to find one of these helper shadow windows in Spy++, you won't find much. Unlike the tooltip_class32 windows, which are long-lived and just hide/show themselves as needed, these shadow windows are a more elusive creature: they are only created for as long as needed, so you'd have to refresh Spy++ while there's a tooltip or popup menu or other window using the shadow present - and that's tricky, since most tooltips and menus will disappear as soon as you move the mouse to switch to Spy++. But it turns out that the tooltips on Spy++'s own toolbar will stick around: so start Spy++, hover over an item in the toolbar, and hit F5 to refresh the HWND tree while the tooltip and shadow are present. Now scroll down, and you should see the third and fourth visible HWNDs in the tree are the tooltip itself, and right after that, a SysShadow window. Unfortunately, since the tooltip and shadow have by now disappeared, if you attempt to get the properties dialog for that HWND, you'll get a get a blank property dialog with an 'Invalid Window' message. If you really want to poke around and see how that SysShadow works, what styles it itself uses and so on, you could create a target app with a long-lived popup that uses CS_DROPSHADOW that you can then explore in Spy++ at leisure.
(Finally, note that these shadows are a completely different thing than the shadows that you see when one app window is on top of another above another since Vista: this type of shadow is part of Aero Glass mode, and handled by the same Desktop Composition Manager that adds the glass titlebar effect, and it doesn't use or need helper windows to implement the shadows.)
I wouldn't be surprised if that shadow is intimately tied to the window manager itself; it is after all the window manager who decides what window gets to paint which parts of itself and when it can do it. I don't see it as rocket science to paint that shadow if control over all that is gained, which the window manager has.
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