MDI window z-order oddity when activating

Question

I have an application with many MDI child windows. Normally, the user is able to bring one MDI child window to the front by clicking on both the client and non-client areas of the window. This seems to normally happen as soon as the mouse button is down.

Now, what sometimes happens is that when the user clicks an MDI child form on its client area, the window does not come to the front as expected. Clicking on the title bar of the form, however, does bring the window to the front, but only when the mouse button is released. This has the effect that the user can drag one MDI child window behind another, and when releasing the mouse button, the dragged window comes to the front.

The effect is that if I have several MDI child windows partially overlapping one another, I cannot bring a window to the front like I normally can. This seems to be independent of the focus - an MDI child window can have focus, but still be behind another MDI child window.

Moreover - this seems to happen randomly, after using the application for a while. I can reproduce the bug using a serialised program state (a 'save' file) sent from a user.

My question has 2 parts: any ideas why this might happen, and how can I debug my program to find out why this happens?

I suspect that a windowing message WM_ACTIVATE (or something similar) is not being handled properly, but this is a C# application and I'm not doing anything unusual with the message queue.

Edit: Here's some additional info from spy++.

Below is the output from spy++ when everything occurs normally:

<00013> 00D209AA S WM_PARENTNOTIFY fwEvent:WM_LBUTTONDOWN xPos:146 yPos:147
<00014> 00D209AA R WM_PARENTNOTIFY
<00015> 00D209AA S WM_WINDOWPOSCHANGING lpwp:0012EE90
<00016> 00D209AA R WM_WINDOWPOSCHANGING
<00017> 00D209AA S WM_CHILDACTIVATE
<00018> 00D209AA S WM_NCPAINT hrgn:D3043A75
<00019> 00D209AA R WM_NCPAINT
<00020> 00D209AA S WM_ERASEBKGND hdc:C20124F7
<00021> 00D209AA S WM_GETTEXTLENGTH
<00022> 00D209AA R WM_GETTEXTLENGTH cch:1
<00023> 00D209AA S WM_GETTEXT cchTextMax:4 lpszText:0012DC48
<00024> 00D209AA R WM_GETTEXT cchCopied:1 lpszText:0012DC48 (" ")
<00025> 00D209AA R WM_ERASEBKGND fErased:True
<00026> 00D209AA S WM_WINDOWPOSCHANGING lpwp:0012EB80
<00027> 00D209AA R WM_WINDOWPOSCHANGING
<00028> 00D209AA S WM_MDIACTIVATE hwndDeactivate:014809AE hwndActivate:00D209AA (activating)
<00029> 00D209AA S WM_NCACTIVATE fActive:True
<00030> 00D209AA R WM_NCACTIVATE
<00031> 00D209AA S WM_IME_SETCONTEXT fSet:1 iShow:C000000F
<00032> 00D209AA R WM_IME_SETCONTEXT
<00033> 00D209AA S WM_SETFOCUS hwndLoseFocus:00B20A2A
<00034> 00D209AA R WM_SETFOCUS
<00035> 00D209AA R WM_MDIACTIVATE
<00036> 00D209AA R WM_CHILDACTIVATE
<00037> 00D209AA S WM_WINDOWPOSCHANGED lpwp:0012EE90
<00038> 00D209AA R WM_WINDOWPOSCHANGED
<00039> 00D209AA S WM_MOUSEACTIVATE hwndTopLevel:012C093A nHittest:HTCLIENT uMsg:WM_LBUTTONDOWN
<00040> 00D209AA R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE

When I get the output from running the application with the bug being reproduced, clicking on the client area produces the following:

<01315> 023E0AA0 S WM_PARENTNOTIFY fwEvent:WM_LBUTTONDOWN xPos:139 yPos:142
<01316> 023E0AA0 R WM_PARENTNOTIFY
<01317> 023E0AA0 S WM_MOUSEACTIVATE hwndTopLevel:012C093A nHittest:HTCLIENT uMsg:WM_LBUTTONDOWN
<01318> 023E0AA0 R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE

Looking at the message numbers, I can immediately see that there are a bunch of messages that are not occurring, specifically, WM_CHILDACTIVATE.

Solution

MdiParent of one of the forms was not being set before the window was being shown.

Answer 1

Here are a few suggestions to try:

• Add a click event to the child form, and on click call Show() to bring the form to the front
• Ensure that MdiParent property is set on all child forms
• Ensure that IsMdiContainer property is set on parent form
• Set WindowState of child forms to Normal
• Use Activate() to activate form and give it focus

You can also try leveraging the z-order from the parent to give focus to the child:

this.ActiveMdiChild.SendToBack();
Control.ControlCollection ct = ((MdiClient)this.ActiveMdiChild.Parent).Controls;
((Form)ct[0]).Activate();

Hopefully one or more of these suggestions will resolve your problem.

Answer 2

The answer to this question may lie deeper in the implementation of your application than you have shared.

Are you using any 3rd party UI libraries? (ex: DevExpress or Telerik or ...) These libraries often use pinvoke win32 apis to achieve some of their nicely skinned windows and/or neat functionality. If you are using plain old winforms that'd be good to know.

The fact that you can reproduce the issue with your saved application state suggests that there is a bug in the way the child windows are created. I would step through the loading of this saved state file to see if all child windows are loaded the same way. This is the kind of problem that could well come down to one single line of code somewhere.

Also if you could gather up multiple saved state files that reproduce the issue you may be able to identify a trend. Perhaps it is one specific window in your application which consistently displays the above behavior?

Contrary to the other suggestion currently on this thread, you should NOT use ShowDialog() for Mdi Children. (I'd even hope Microsoft throws an exception if you try to ShowDialog with an MdiParent assigned to the form). MdiChildren are not permitted to be modal windows and this could very well cause the kind of bad behavior you are seeing. ex: One form wants to be modal/ontop while a normal child form is trying to get focus.