"Zach Gorman" zach@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.
From: Dmitry Timoshkov [mailto:dmitry@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