WebBrowser control on MFC property page - need to handle TAB key presses

1
votes

I'm trying to host the .NET Windows Forms WebBrowser control on an MFC property page. To do this I'm using the CWinFormsControls class. This all works quite nicely, but since I'm on a property page there seems to be a problem with the property sheet consuming TAB and RETURN key presses to perform navigation or default key press behaviour, i.e. pressing the TAB key when the web browser control has focus does not move focus to the next control in the web page (the page has a username and password edit box plus a 'Submit' button and I'd like TAB to move between the boxes on the page and for RETURN to submit). End users aren't going to be satisfied with this mouse-only behaviour so I need the web browser to handle TAB and RETURN keys rather than the property sheet.

After some research - I'm a novice when it comes to MFC and WinForms - I think the problem may be that the property page is consuming these keys thanks to IsDialogMessage, which internally sends a WM_GETDLGCODE message to the web browser and the web browser only returning DLGC_WANTARROWS and DLGC_WANTCHARS, but crucially not returning DLGC_WANTTAB. So the web browser never sees the TAB key to handle it.

So I've tried many things, but the most promising approach appeared to be deriving my own control from WebBrowser and then overriding the WndProc function to explicitly handle WM_GETDLGCODE messages and request the TAB key:

protected override void WndProc(ref Message m)
{
    if (m.Msg == 0x87 /* WM_GETDLGCODE */)         {
        m.Result = (IntPtr)0x83; // DLGC_WANTARROWS|DLGC_WANTTAB|DLGC_WANTCHARS
    } else {
        base.WndProc(ref m);
    }
}

And this function does actually get called. However, the TAB keys still don't work. Attaching Spy++ to the web browser window reveals that despite appearing to handle WM_GETDLGCODE, the response isn't as expected:

spy++ output

Which I can't explain and obviously doesn't solve the problem.

So, am I going about this the right way? Is there a 'correct' solution to this problem?

I've tried using PreTranslateMessage to explicitly intercept TAB and RETURN key presses and somehow (SendKeys API) send them to the web browser control. This worked for TAB keys but caused a buffer overrun for the RETURN key. So no luck there and it felt like a nasty hack anyway.

This post is already getting long. If you need any more info then just ask. All help very gratefully appreciated.

2
c#winformsmfcwebbrowser-control

2 Answers

0
votes

After some research it seems that the better solution was to derive my own class from CPropertyPage and have that override PreTranslateMessage as:

BOOL CMyPage::PreTranslateMessage(MSG* pMsg)
{
    return CDialog::PreTranslateMessage(pMsg);
}

i.e. make the property page behave as though it's a regular dialog. The reason for this is that property pages defer to the parent property sheet to handle key presses such as TAB and RETURN.

With this minor change my web browser control is getting all of the key presses and behaving as intended.

-1
votes

In case this helps someone, I was running my webBrowser in a modeless dialog. In the PretranslateMessage I had to do this for tabs, delete-keys and Enter-key to work correctly:

BOOL CMyDialog::PreTranslateMessage(::MSG *pMsg)
{
   if (System::Windows::Interop::ComponentDispatcher::RaiseThreadMessage(*reinterpret_cast<System::Windows::Interop::MSG*>(pMsg)))
      return TRUE;
else
   return CVSimWnd::PreTranslateMessage(pMsg);
}