ATL composite controls inside an MFC container
I did manage to find a solution to this problem, although it is not a very
neat one. I handle PreTranslateMessage() in my MFC view and filter out all
keyboard messages for special processing. If the keyboard message is
destined for the ActiveX control or descendant I do the following things,
otherwise I just call the base class PreTranslateMessage().
// allow tooltip messages to be filtered
if(CWnd::PreTranslateMessage(pMsg))
{
return TRUE; // message handled
Quote:
}
// translate the message
(void)TranslateMessage(pMsg);
// send the message to the target window
// pWndMsg is obtained from pMsg.hwnd
(void)pWndMsg->SendMessage(
pMsg->message,pMsg->wParam,pMsg->lParam);
return TRUE; // message handled
There is extra work to do if your application uses keyboard accelerators but
nothing too difficult. This seems to work ok for me so far.
David Shepherd
Quote:
> I don't know the answer. I don't use MFC myself. Look at KB Article
> Q92905 "DlgTab.exe - Infinite Loop Moving Through Dialog Ctrl", but the
> last time I've seen a similar problem, WS_EX_CONTROLPARENT helped and
> this article didn't.
> See if this helps. If not, and if you can create a small sample that
> reproduces the problem, I would like to look at it. You can e-mail it to
> me if you want.
> --
> With best wishes,
> Igor Tandetnik
> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken
> > Igor
> > Thank you for the information regarding WS_EX_CONTROLPARENT. I added
> this
> > style when creating my CAxWindow's, but the problem is still there. I
> have
> > been looking some more at what MFC does when it receives a character
> key
> > press. The following simplified things happen on the embedded control
> > (a) The controls PreTranslateAccellerator function is called to see if
> it
> > handles the keyboard input.
> > (b) If not, the WM_GETDLGCODE message is sent to the control to
> determine if
> > it handles the keyboard input.
> > (c) If not, MFC goes into an infinite loop trying to do something with
> > dialog mnemonics. I think the loop is caused because the embedded
> control is
> > not a direct child of the MFC view.
> > If I force the de{*filter*} to skip over steps (a) to (c) the last thing
> MFC
> > does is to call IsDialogMessage, this makes the computer beep. If I
> skip
> > IsDialogMessage also, everything works fine and the key press ends up
> in the
> > embedded control where it should be.
> > From this, it looks like
> > (a) MFC has a bug in its dialog mnemonic code (this problem has gone
> away in
> > version 7).
> > (b) IsDialogMessage is doing something to prevent the key press
> reaching the
> > embedded control.
> > I am now stuck :)
> > Any other suggestions would be greatly appreciated.
> > David Shepherd
> > > Known problem. When creating new controls with CAxWindow::Create,
> > > specify WS_EX_CONTROLPARENT style. For more information on why it's
> > > needed, see KB Article Q149501 "PRB: Child CPropertySheet Hangs If
> Focus
> > > Is Switched"
> > > --
> > > With best wishes,
> > > Igor Tandetnik
> > > "For every complex problem, there is a solution that is simple,
> neat,
> > > and wrong." H.L. Mencken
> > > > I have an ActiveX control written in ATL. This control Uses
> CAxWindow
> > > to
> > > > host additional ActiveX controls within its self. This setup works
> > > fine
> > > > under Visual Basic, but under MFC(42), if the focus is set to one
> of
> > > the
> > > > contained controls, and a character key is pressed, the
> application
> > > goes
> > > > into an infinite loop.
> > > > Stack trace
> > > > _AfxFindNextMnem <---- infinite loop here
> > > > _AfxGetNextMnem
> > > > COccManager::IsDialogMessageA
> > > > CWnd::IsDialogMessageA
> > > > CWnd::PreTranslateInput
> > > > CFormView::PreTranslateMessage
> > > > CWnd::WalkPreTranslateTree
> > > > CWinThread::PreTranslateMessage
> > > > CWinThread::PumpMessage
> > > > The controls I am having most trouble with are Microsoft Forms
> > > controls
> > > > (FM20.dll).
> > > > Does anyone know what is happening here. Is it a bug in MFC ? or
> do i
> > > need
> > > > to write some extra code to handle the contained controls ?
> > > > TIA
> > > > David Shepherd
