ATL composite controls inside an MFC container 
Author Message
 ATL composite controls inside an MFC container

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



Wed, 09 Mar 2005 01:20:51 GMT  
 ATL composite controls inside an MFC container
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


Quote:
> 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



Wed, 09 Mar 2005 02:26:01 GMT  
 ATL composite controls inside an MFC container
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


Quote:
> 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



Wed, 09 Mar 2005 19:49:42 GMT  
 ATL composite controls inside an MFC container
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


Quote:
> 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



Fri, 11 Mar 2005 21:51:22 GMT  
 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



Wed, 06 Apr 2005 05:39:59 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. ATL composite controls inside an MFC container

2. Troubles with MSChart inside an ATL composite control

3. Automatic resizing of ATL composite control inside IE page

4. ATL(+MFC) Composite control VS MFC ActiveX Contol

5. mfc control in atl composite control wont destruct

6. mfc control instantiated in atl composite control using CAxWindow wont destruct

7. Help - Problems with Drawing an MFC ActiveX control inside on ATL compsoite control

8. Problems with Drawing an MFC ActiveX control inside on ATL compsoite control

9. Dynamically Create ATL composite control on MFC based application

10. Handling Messages for MFC child dilaogs in an ATL Composite Control

11. MFC dialog from ATL composite control

12. Handling Messages for MFC child dilaogs in an ATL Composite Control

 

 
Powered by phpBB® Forum Software