Home Dashboard Directory Help

MFC Tabbed MDI bug. by David Webber


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 676869
Opened: 6/24/2011 10:07:00 AM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
User(s) can reproduce this bug


An MFC tabbed MDI application has the following undesired behaviour (under Windows 7):

1. I open two documents in the application.
2. I minimise the main frame.
3. I restore the main frame by clicking on one of the two document thumbnails above the program icon on the task bar.

The appropriate document comes up as the current one, but

a. it doesn't get the focus properly.
b. the tool bars are not drawn correctly - the area outside the buttons is black.

I have produced this behaviour in a small app created with re VS2010 wizard. [The focus isn't obvious in the blank documents but the tool bar problem is clear.]

What appears to be happening is that, when the frame is restored, CView::OnActivateView gets called but the line

if (IsTopParentActive()) SetFocus();

is finding thatthe parent is not active, so SetFocus() does not get called.

Everything is apparently restored to a correct state, toolbar apearance included, if I click on the tab of the other document, and stays correct if I thien click on the first one again.

Can you confirm this is a bug? I attach the mini app I created to demonstrate it (in which all code is as generated by the App Wizard).

David Webber
Sign in to post a comment.
Posted by Microsoft on 10/25/2011 at 10:01 AM
Hello David,

Thanks again for the report. This issue has been fixed in MFC for the next major release of Visual Studio.

Pat Brenner
Visual C++ Libraries Development
Posted by David Webber on 7/2/2011 at 4:03 AM
I can now demonstrate the problem with the view.

I attach ActivationTest2.zip, the same project created with the app-wizard, to which I have added (only) OnSetFocus() and OnKillFocus() handlers to the view. These simply output the hWnds of the window losing and gaining the focus using OutputDebugString().

Run this in Windows 7 in debug mode from the VS 2010 IDE.

Open a 2nd view window in the application with File/new.

Go to the taskbar icon, and click on the thumbnail of the view which is NOT the top one.
It comes to the top (as seen from the tabs) but does NOT receive a WM_SETFOCUS message.

Alternate between the two views, by clicking on the taskbar thumbnails. The one you're leaving does get a WM_KILLFOCUS, but the one you're entering does not get a WM_SETFOCUS. The OnKillFocus() output indicates that no window is receiving the focus.

I hope this hopes you locate the problem. (Any ideas on a work-around?)

Posted by David Webber on 6/30/2011 at 12:59 PM
Whilst I have found a work-around to the toolbar appearance problem (see work-arounds), the View is not always being fully activeted whan restoring the application from the minimised state - in that its caret does not appear. (This is not testable with the mini app I submitted as it doesn't have a caret in the view.)

I have done some further research on this:

A) In Windows 7 with 1 View window open:
A1) Clicking on the task bar icon: restores everything complete with caret in the view.
A2) Hovering over the task bar icon and clicking in the thumbnail: doesn't get me the caret in the View.

B) In Windows 7 with two MDI tabbed views open:
I have to do the equivalent of A2 in one of the two thumnails, and I don't get my caret.

C) In Windows Vista, there is only ever one thumbnail, however many views are open, and I have to click on the task bar icon to restore the app from minimised. I get my caret and all is well.

D) in Windows XP there are no thumbnails. I have to click on the task bar icon to restore the app from minimised. I get my caret and all is well.

So the incomplete activation seems to be to do with clicking on the thumbnail in the view. SetFocus() and MDIActivate() don't seem to help. Is there a work-around for this?

David Webber
Posted by MS-Moderator08 [Feedback Moderator] on 6/28/2011 at 2:27 AM
Thank you for quick response. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. We will contact you if we require any additional information.
Posted by David Webber on 6/27/2011 at 3:33 AM
The mini project is now added as a zip file. Sorry about the delay - it must have failed when I tried originally.

David Webber
Posted by MS-Moderator08 on 6/26/2011 at 10:47 PM
Thank you for reporting this issue. Could you please attach the mini app and some screenshots to this bug?
Posted by MS-Moderator01 on 6/24/2011 at 10:49 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by David Webber on 6/30/2011 at 12:53 PM
A partial work around:

I have managed to restore the appearance of the tool bars by a fairly horrible kludge as follows:

1. In response to WM_SIZE in the CMainFrame:

If the window is being minimised, set a member

m_bMin = TRUE

2. In the application's OnIdle() function, call:

void CMainFrame::Kludge()
    if( m_bMin && !IsIconic() )
        m_bMin = FALSE;

This does not always, however, completely activate the appropriate view, when the minimised frame is restored, in that its caret does not appear. (This is not testable with the mini app I submitted as it doesn't have a caret in the view.)

David Webber
File Name Submitted By Submitted On File Size  
ActivationTest.zip 6/27/2011 131 KB
ActivationTest2.zip 7/2/2011 219 KB