Way to detect DWM open/close window animations?

Plain GDI. GDI+ is an option but I don't think it would help here. I can't use WPF as it's a C++ app.

The effects window I'm overlaying has a static copy of what the main window used to look like. On to that I'm using DWM to render a live copy of the main window. The live copy scrolls/fades/zooms to give a smooth transition from the old UI state to the new one.

Doing it this way means the existing UI elements don't need to be modified for the effect to work; they just paint themselves as normal. During the transition the UI remains "live", painting updates and responding to the mouse and keyboard (since the effects window is "click-through"). With just two lines of code I can add a transition effect to almost any UI change.

It all seems to work great, except if the effect is triggered while DWM is applying its own transition animations to the window. So if I could just detect when/whether those are happening I could disable my effect.

(Obviously I also have to worry about the main window being moved or resized while the effects window is over the top of it. That is easy enough. The problem with the DWM animations is that they visually move the window and yet it doesn't move as far as things like GetWindowRect or WM_SIZE are concerned.)

Maybe a picture shows it better. Say notepad is opening:

(It's actually a screenshot of notepad closing, as that was easier to capture, but just pretend it's opening instead. )

If you were to overlay a copy of its client area on top of where the OS reports it to be, you'd end up with this:

I think that's using C++/CLI so it'd turn my app into a managed one which I want to avoid. (On the grounds of avoiding complexity, if nothing else.)

Not sure WPF would solve the problem anyway, unless the whole UI was re-written as WPF? When WPF and Win32 are used in the same window they have to be segregated (no overlapping controls/regions). They can share a window but they can't interact, at least as I understand it.

My aim is to make something that can be slotted into existing code without much plumbing and without having to change the way existing controls paint themselves or the way they are hosted in the window.

DWM's live-thumbnail API is perfect for that as it lets me render a live copy of the window, faded/enlarged/reduced. From just messing around with it for a day I've got something that's almost perfect, except when DWM is messing with my window's shape in a way I don't know how to detect.

(Hope that makes sense. Probably not explaining myself very well at 4am. )

There's too much existing UI code in the project to make porting to WPF a realistic option. It also hosts several native 3rd party UI components that don't have WPF equivalents. An all-WPF UI would definitely make this kind of thing easier if it was a new or small project but it'd take man-years to change the existing project.

Using WPF for individual controls in the UI would be fine, but I want something which can apply effects on top of existing controls/window regions.

Hmm, I wonder if there's a way to make DWM treat two top-level windows as part of the same thing, applying the same animations & transforms to both at once? That would solve things as well.

They're all HWNDs but that doesn't mean WPF can draw a window that displays a modified copy of my native windows on top of those windows (which is what I'm doing at the moment), due to the "airspace restrictions".

As far as I can tell, mixing WPF and native controls just means they can sit next to each other in the same window. I don't think they can visually interact/overlap.

The effects window can't be a proper child (WS_CHILD) of the main window since DWM thumbnails can only be drawn into top-level windows.

(Drawing the thumbnail directly into the main window won't work as the thumbnail is of the main window and DWM checks for such loops.)

When I create the effects window as a popup (WS_POPUP) I am specifying the main window as the parent in the CreateWindowEx call, but that doesn't seem to help. It opens in-place instantly instead of being animated like the main window is.

If I call SetParent on the effects window right after creating it, specifying the main window as its parent, then that breaks the DWM thumbnail.

It is a bit of a hack, but one which works well (so far, at least) apart from this one issue.

Spending the next few years re-writing the entire app to get a bit of eye candy isn't an option, as nice as that idea may sound in an ideal world with infinite time & resources and access to the source code of all OS and 3rd party components. (This effect has to work, for example, on hosted ActiveX controls.) If re-writing the whole app is the only option then I'll simply do without the effect.

However, if there is some way to detect when DWM has finished animating my window then I believe I can make everything work perfectly.

Flip3D is fine, FWIW. You can opt windows out of it so the overlay window would be hidden whenever it's active (including when it's animating things into position).

Think I'll explore an alternative way to do the effect now. Have an idea that might give a good result but won't be hardware accelerated and will only work with windows that allow painting to a specific device-context. If that works well enough then it'll save a lot of hassle.

I gave up on the alternative method in the end. Ran into too many problems with controls drawing directly into the window, or directly manipulating the window (e.g. shifting parts of it around in when scrolling), over the top of what I was doing. That's what makes the DWM thumbnail method so great: It takes the rendering output or the windows and does things to it without affecting it at all. (It also lets me easily create effects on areas of the top-level window which can cross over child windows.)

So I went back to plan A. Almost ditched the idea completely but it looked so nice (to me ) that I kept at it a bit more, and I think I now have it working really well, albeit with some kludges. Long term testing will determine whether the feature sticks or is canned.

While playing with this stuff I discovered that Windows 7's DWM process will crash (and sometimes reset the desktop back to classic rendering) if the user invokes Aero Peek while a DWM thumbnail is being moved around in another window as Peek fades things out to sheets of glass.

Workaround is to set the new DWM window flag on the window the thumbnail is rendered into, telling DWM to ignore that window for Aero Peek. (Drawback is that it then stays visible while the other windows are faded to glass, but in my case that's fine as it's only visible for half a second anyway.)

I also noticed that my overlay window is considered part of the main window when minimising/restoring the window, and within Flip 3D. So it's only considered a separate window during the window-open animation, which seems weird. It's like the pop-up is only "attached" to its parent after that window-open animation has completed. (I checked that I'm not opening my pop-up before the parent window has been made visible, and I'm not.)