🚀 go-pugleaf

"nicolasr" <nicolasrNOSPAMATSIGNgmx.net> wrote in message
news:3fd5198f@newsgroups.borland.com...

> I just want to understand how to map the standard painting to
> the UpdateLayeredWindow() mechanism.

You don't.  UpdateLayeredWindow() replaces the standard painting mechanism,
it does not supplement it.  If you use WM_PAINT, then you don't use
UpdateLayeredWindow(), and vice versa:

    (from MSDN)
    "Note that when using UpdateLayeredWindow the application doesn't need
to respond to WM_PAINT or other painting messages, because it has already
provided the visual representation for the window and the system will take
care of storing that image, composing it, and rendering it on the screen.
UpdateLayeredWindow is quite powerful, but it often requires modifying the
way an existing Win32 application draws."

> If I understand correctly I should call UpdateLayeredWindow()
> whenever some visual aspect of my main window changes.

If your main window has the WS_EX_LAYERED style and is using
UpdateLayeredWindow(), then yes.

> This would include such basic things as a button is pressed,
> correct?

No.  Every window handles its own painting.  You would call
UpdateLayeredWindow() only for the layered window that is actually changing.

> The problem is: where do I react to those changes? Would it
> be possible to intercept the WM_PAINT mechanism myself,
> let the entire form, including all child controls, render into a
> buffer bitmap and than call UpdateLayeredWindow()?

If you enable the window to work with UpdateLayeredWindow(), then it won't
receive the WM_PAINT message in the first place.  The application is
responsible for providing the OS with a new bitmap containing changes to the
window, and then the OS simply displays the changes, and remembers the new
image for future redrawing until the application changes the bitmap again.

> At least this seems to be what SetLayeredWindowAttributes()
> is resulting in?

SetLayeredWindowAttributes() tells the system to redirect normal WM_PAINT
drawings to an off-screen bitmap.  WM_PAINT has always provided the
application an HDC to which it is supposed to do its drawing.  When you use
SetLayeredWindowAttributes(), all the OS is doing is changing which HDC is
provided, and then does some extra maintenance internally after the message
handler returns.

But again, if you use WM_PAINT (and thus SetLayeredWindowAttributes()), then
you do not use UpdateLayeredWindow() at all, and vice versa.  They are two
completely different ways for drawing windows.  In fact, if you use
SetLayeredWindowAttributes(), then UpdateLayeredWindow() will actual fail:

    (from MSDN)
    "Please remember that once SetLayeredWindowAttributes has been called on
a layered window, subsequent UpdateLayeredWindow calls will fail until the
layering style bit is cleared and set again. This is because
SetLayeredWindowAttributes turns on the redirection of the window's drawing,
and once that happens UpdateLayeredWindow can give contradictory information
as to what the window really looks like."


Gambit