Re: Last-chance deactivation of MDI Child before destruction

[Dmitry Timoshkov]

"Zach Gorman" <zach(a)archetypeauction.com> wrote:
> Changelog:
> If, during destruction of an MDI child frame, the application
> re-activates the window that is about to be destroyed, de-activate
> it one last time.
>
> Background:
> This resolves an obscure problem caused by a difference in Windows
> and Wine behavior. I have an MDI MFC app in which one of the MDI
> child frames forces itself to stay at the back of the Z-order by
> responding to MDI Activate messages, and re-activating the old
> window (yes I know this is nasty). When Wine tries to switch the
> active MDI child during the active child's destruction, this causes
> the about-to-be-destroyed window to become active again. Windows
> will issue one last WM_MDIACTIVATE to deactivate the window that
> will be destroyed in this case, but Wine won't. This patch corrects
> that difference in behavior.

What happens if that additional WM_MDIACTIVATE won't deactivate an MDI
child either, or an app doesn't allow deactivation for some reason?
Anyway, please add another MDI message test case showing what Windows
does in that case because your change is not obvious at all.

-- 
Dmitry.

Last-chance deactivation of MDI Child before destruction

[Zach Gorman]

> From: Dmitry Timoshkov [mailto:dmitry(a)baikal.ru]
>
> What happens if that additional WM_MDIACTIVATE won't deactivate an MDI
> child either, or an app doesn't allow deactivation for some reason?
> Anyway, please add another MDI message test case showing what Windows
> does in that case because your change is not obvious at all.

> From what I've just seen, if a window tries to activate itself upon becoming
> deactivated in its WM_MDIACTIVATE handler, there is no effect at all. Only
> the handler for the window that is becoming activated can, in turn, activate
> a different window instead. This indicates that the second attempt in
> Windows to deactivate won't fail, because it is not activating another
> window on the second go.

Yes, this behavior is a bit odd and a regression test is warranted. I was
afraid someone would ask for one :) I'll see if I can find some time to work
on that this week.

Zach