FIX: Web Browser Control Hangs in CFormView (164813)

SYMPTOMS

Under certain circumstances, The Microsoft Web Browser Control may appear to hang when used in a CFormView derived class. The control will actually be caught in an infinitely cascading loop of focus messages.

CAUSE

Microsoft Foundation Classes (MFC) has to handle focus for child items in the modeless dialog in a CFormView.

When focus leaves the dialog, MFC remembers where the focus was. When focus returns, MFC tries to set it back to the place where it used to be. It's possible for a situation to exist where the window that MFC wants to set the focus back to no longer exists.

RESOLUTION

To avoid this problem, it is necessary to handle the WM_SETFOCUS message. This handler can be added with the Class Wizard. To do this, it is necessary to change the Class Wizard Message Filter. This can be done by choosing the Class Info tab of the Class Wizard and selecting Window as the message filter for the class under Advanced Options. Once this is done, you will be able to select WM_SETFOCUS in the Message Maps tab for the CFormView derived class.

The WM_SETFOCUS message handler should look similar to the following:

   void CMyFormView::OnSetFocus(CWnd* pOldWnd)
   {
      if (!::IsWindow(m_hWndFocus) || !::IsChild(m_hWnd, m_hWndFocus))
      {
         // invalid or unknown focus window... let windows handle it
         m_hWndFocus = NULL;
         Default();
         return;
      }
      // otherwise, set focus to the last known focus window
      ::SetFocus(m_hWndFocus);
   }

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. This bug has been corrected in Visual Studio 97 Service Pack 1.

For additional information about the Visual Studio 97 Service Pack 1, please see the following article in the Microsoft Knowledge Base:

170365 INFO: Visual Studio 97 Service Packs - What, Where, and Why

MORE INFORMATION

The following illustrates a situation in which this problem might occur:

Navigate to a URL that has a child window or causes a child window to appear.
Put focus on the child window.
Navigate to a different URL.
Immediately set focus to a different application.
At step 4, MFC will save the child window handle that previously had focus. Step 3 will eventually cause the window to be destroyed, though. So, when you:
Set focus back to the application.

MFC will try to set focus to the now-deceased child window and fail, resulting in an infinitely cascading loop of focus messages.