WS_EX_LAYERED/UpdateLayeredWindow with owned WS_CHILD windows

[XPCODER]

All:

I successfully implemented a WS_POPUP main window using the WS_EX_LAYERED
style and UpdateLayeredWindow (in XP SP2). The per-pixel alphablend works
perfectly for the rounded corners and drop shadow that I have.

The issue is that when I attempted to place some WS_CHILD windows on the
WS_POPUP main window, they don't render. Spy++ shows that they exist and
respond to mouse messages (for example). I then searched the web and found a
forum reference to a WinForm C# program that mentioned that child controls
don't show up on a WS_EX_LAYERED window. (It didn't explicitly mention the
WS_CHILD style, but that seemed a safe assumption.) I didn't find much else
on the web for this specific issue.

My workaround, at this time, is to re-style the WS_CHILD windows as WS_POPUP
instead (with the necessary coord translation). However, it seems
extraordinary that I should need to do this.

Am I missing something obvious, or is this really a limitation with
UpdateLayeredWindow? Is there a "natural" way to place WS_CHILD windows on an
owner window that has the WS_EX_LAYERED style?

Thanks.

[Ivan Brugiolo [MSFT]]

Your original approach is not going to work.
Rember that an ULW window does not paint, and, it does
not receive WM_PAINT messages as well.
It produces content in some private/custom/uninteresting way,
and, it indicates the new content to the system,
via UpdateLayeredWindow, and that's it.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"XPCODER" <XPC...@discussions.microsoft.com> wrote in message
news:7C756CB8-B638-4FD6...@microsoft.com...

[XPCODER]

Ivan:

Thanks for the reply; however, it doesn't appear to address the issue if I
understand your response.

I understand that a ULW window does not receive WM_PAINT messages. I already
have successful implementation to ensure that visual updates produce calls
to UpdateLayeredWindow. Moreover, technically, the WM_PAINT message to a
"normal" (non-ULW) owner window would not really involve WS_CHILD windows
anyway (they'd get their own WM_PAINT messages as needed).

My issue is with child windows of an ULW owner window and why they don't
render at all. So, are you saying that because the owner ULW window does not
receive WM_PAINT messages, that this characteristic/feature ensures that
WS_CHILD child windows won't get WM_PAINT messages either?

[In one of the test iterations, I believe that I tested showing the child
windows with both ShowWindow and InvalidateRect (and the latter, at least,
should have produced a WM_PAINT to the child window), but these did not work
either.]

So, can you answer:
1. Whether an owner ULW window causes the WM_PAINT message to be surpressed
to all WS_CHILD child windows?
2. If the WM_PAINT message is suppressed, is there any way to cause the
WM_PAINT message to be issued to the child window? and/or,
3. besides using WS_POPUP windows (as I'm now doing), is there any way of
causing WS_CHILD windows to render on top of a owner ULW window?

Thanks.

[Ivan Brugiolo [MSFT]]

The problem is not if they receive WM_PAINT or not, but the paint model.
Assume you have a window that sets a WM_TIMER, and, in the timer,
it does something like GetDC(hWnd),LineTo(hDc,...),ReleaseDC.
None of the drawing would go through, because the only way to update
the UnderLay of an ULW-Window is through UpdadeLayeredWindow.

My take of youw WS_POPUP trick is that you make your `child`
window top-level window, and, top-level window are allowed to
paint any way they feel, because they are not rooted under a layered
parent, but, they are children of the desktop.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"XPCODER" <XPC...@discussions.microsoft.com> wrote in message

news:7D3A1799-AC8B-4DFF...@microsoft.com...

[sushi_cw]

I was recently working on a similar problem and ran into the same limitation.

The workaround I ended up using was to do the alpha blending manually: I'd
bitblt out the underlying window, use AlphaBlend to set my control background
in WM_ERASE, and then let WM_PAINT et all proceed normally. It's working
fairly well, although my particular situation doesn't have to worry about
complex child windows or windows moving on top of each other.

[Chris Becke]

Its been a while so some of my memory might be flakey..

However, child windows do NOT recieve their own WM_PAINT messages. In order
to co-ordinate painting, all the painting of child windows is co0ordinated
with the parent windows WM_PAINT - so that things like CLIPSIBLINGS etc. can
be implemented.

As a result, if the parent window is not recieving WM_PAINT messages, there
is no way for the child messages to get it. What you need to do essentially
is mimic the normal paint logic in your ULW handler.

i.e. get your offscreen source DC that you are going to pass into ULW, draw
your windows background onto it using your normal logic, THEN enuemrate over
your child windows, manually sending each one a WM_PAINT or WM_PRINT. With
WM_PAINT its hard to ensure the windows get the *right* HDC as theres no
requirement for windows to use the wParam as an HDC if not null, just a
convention. I belive most of the standard controls do support this method
however.

Then, with the 'compatible' child windows blitted onto your offscreen DC,
call ULW with the result.

The real trick is, if any of the child windows needs to be UI interactive,
is how to ensure that you call ULW when they call InvalidateRect on
themselves.

"XPCODER" <XPC...@discussions.microsoft.com> wrote in message

news:7D3A1799-AC8B-4DFF...@microsoft.com...