From: Dylan Bourque on
After recently converting our application from VS 6/MFC 6 to VS 2005/MFC 8.0,
I'm getting an assertion failure in CPtrList::GetNext() [at line 356 in
afxcoll.inl] when it's called from _AfxFindNextMnem() [line 201 in
occdlg.cpp] when pressing any key with the focus inside my main application
window.

For background, we have a fairly large medical records management
application that uses MFC as a core support framework, but we have our own
object model built on top of the basic CWinApp/CWinThread/CWnd MFC objects.

Here's the window hierarchy for the application:
C_MainWnd (CWnd-based frame window)
-- C_HomeView (CWnd-based "view" window)
-- C_HtmlCtrl (CWnd-based custom control)
-- CWnd* to MS HTML browser control hosting HTML pages

The input focus is on browser control when I press the key. Execution falls
into our C_HomeView::PreTranslateMessage(), which eventually calls
CWnd::IsDialogMessage() for the WM_CHAR message. After stepping into the MFC
source, I eventually get to a call to pWndDlg->GetControlContainer() [at line
188 in occdlg.cpp] with pWndDlg pointing to my C_HomeView object which
returns a valid (as far as I can tell) COleControlContainer pointer. Right
after that [at line 192], the code calls
pCtrlCont->m_listSitesOrWnds.GetHeadPosition(), which returns 0. The
subsequent call to pCtrlCont->m_listSitesOrWnds.GetNext(pos) [at line 201]
triggers the assertion (then an MFC invalid argument exception).

I've examined the relevant objects in the debugger and this is what I've
come up with:
1) m_listSitesOrWnds is empty for the C_HomeView window.
2) m_listSitesOrWnds is NOT empty fot the C_HtmlCtrl window. An entry is
added to the list during C_HtmlCtrl::OnCreate() when we call CreateControl()
to create the ActiveX control.

The 6.x and 8.x implementations of _AfxFindNextMnem() are drastically
different, but I would assume that the new function should be checking for an
empty list before trying to get the 0-th element and generating the
assertion/exception.

Has anyone else seen this behavior? Can anyone point me in a direction to
address the problem? We're several months into moving our product from VS 6
to VS 2005 and I'm pretty desperate.

Thanks in advance for any help.

Dylan Bourque
Lewis Computer Services
From: jiangsheng[MVP] on
If possible, use the STL list class as the container.

--
Regards
Sheng Jiang

Microsoft Most Valuable Professional in Visual C++
http://www.jiangsheng.net
http://blog.joycode.com/jiangsheng/
"Dylan Bourque" <DylanBourque(a)discussions.microsoft.com> ??????
news:8A64EE98-9549-46AE-880F-5ADE3BB5F2D4(a)microsoft.com...
> After recently converting our application from VS 6/MFC 6 to VS 2005/MFC
8.0,
> I'm getting an assertion failure in CPtrList::GetNext() [at line 356 in
> afxcoll.inl] when it's called from _AfxFindNextMnem() [line 201 in
> occdlg.cpp] when pressing any key with the focus inside my main
application
> window.
>
> For background, we have a fairly large medical records management
> application that uses MFC as a core support framework, but we have our own
> object model built on top of the basic CWinApp/CWinThread/CWnd MFC
objects.
>
> Here's the window hierarchy for the application:
> C_MainWnd (CWnd-based frame window)
> -- C_HomeView (CWnd-based "view" window)
> -- C_HtmlCtrl (CWnd-based custom control)
> -- CWnd* to MS HTML browser control hosting HTML pages
>
> The input focus is on browser control when I press the key. Execution
falls
> into our C_HomeView::PreTranslateMessage(), which eventually calls
> CWnd::IsDialogMessage() for the WM_CHAR message. After stepping into the
MFC
> source, I eventually get to a call to pWndDlg->GetControlContainer() [at
line
> 188 in occdlg.cpp] with pWndDlg pointing to my C_HomeView object which
> returns a valid (as far as I can tell) COleControlContainer pointer.
Right
> after that [at line 192], the code calls
> pCtrlCont->m_listSitesOrWnds.GetHeadPosition(), which returns 0. The
> subsequent call to pCtrlCont->m_listSitesOrWnds.GetNext(pos) [at line 201]
> triggers the assertion (then an MFC invalid argument exception).
>
> I've examined the relevant objects in the debugger and this is what I've
> come up with:
> 1) m_listSitesOrWnds is empty for the C_HomeView window.
> 2) m_listSitesOrWnds is NOT empty fot the C_HtmlCtrl window. An entry is
> added to the list during C_HtmlCtrl::OnCreate() when we call
CreateControl()
> to create the ActiveX control.
>
> The 6.x and 8.x implementations of _AfxFindNextMnem() are drastically
> different, but I would assume that the new function should be checking for
an
> empty list before trying to get the 0-th element and generating the
> assertion/exception.
>
> Has anyone else seen this behavior? Can anyone point me in a direction to
> address the problem? We're several months into moving our product from VS
6
> to VS 2005 and I'm pretty desperate.
>
> Thanks in advance for any help.
>
> Dylan Bourque
> Lewis Computer Services


From: Dylan Bourque on
The "container" is inside MFC's COleControlContainer, so I can't change it.

To clarify a little more, a couple of years ago we discovered that tabbing
between non-ActiveX controls [1, below] and ActiveX controls [2] (that are
not direct children of the common ancestor) on a form doesn't work unless the
common parent window has had InitControlContainer() called on it.

parent window (dialog)
|- standard Win32 text box (1)
|- custom control
|- browser Active X control (2)

We did this (made sure that InitControlContainer() got called on the parent
window) and it worked perfectly in MFC 6.0. After moving up to VS 2005/MFC
8.0, we get an ASSERT and and unhandled exception inside _AfxFindNextMnem()
when it tries to access the empty m_listSitesOrWnds for the outer dialog
window's COleControlContainer.

I'm posting here because I noticed the drastic differences between the
_AfxGetNextMnem() function between MFC 6.0 and 8.0. Any help would be
greately appreciated.

Dylan Bourque
dbourque at lewis dot com
Lewis Computer Services

"jiangsheng[MVP]" wrote:

> If possible, use the STL list class as the container.
>
> --
> Regards
> Sheng Jiang
>
> Microsoft Most Valuable Professional in Visual C++
> http://www.jiangsheng.net
> http://blog.joycode.com/jiangsheng/
> "Dylan Bourque" <DylanBourque(a)discussions.microsoft.com> дÈëÓʼþ
> news:8A64EE98-9549-46AE-880F-5ADE3BB5F2D4(a)microsoft.com...
> > After recently converting our application from VS 6/MFC 6 to VS 2005/MFC
> 8.0,
> > I'm getting an assertion failure in CPtrList::GetNext() [at line 356 in
> > afxcoll.inl] when it's called from _AfxFindNextMnem() [line 201 in
> > occdlg.cpp] when pressing any key with the focus inside my main
> application
> > window.
> >
> > For background, we have a fairly large medical records management
> > application that uses MFC as a core support framework, but we have our own
> > object model built on top of the basic CWinApp/CWinThread/CWnd MFC
> objects.
> >
> > Here's the window hierarchy for the application:
> > C_MainWnd (CWnd-based frame window)
> > -- C_HomeView (CWnd-based "view" window)
> > -- C_HtmlCtrl (CWnd-based custom control)
> > -- CWnd* to MS HTML browser control hosting HTML pages
> >
> > The input focus is on browser control when I press the key. Execution
> falls
> > into our C_HomeView::PreTranslateMessage(), which eventually calls
> > CWnd::IsDialogMessage() for the WM_CHAR message. After stepping into the
> MFC
> > source, I eventually get to a call to pWndDlg->GetControlContainer() [at
> line
> > 188 in occdlg.cpp] with pWndDlg pointing to my C_HomeView object which
> > returns a valid (as far as I can tell) COleControlContainer pointer.
> Right
> > after that [at line 192], the code calls
> > pCtrlCont->m_listSitesOrWnds.GetHeadPosition(), which returns 0. The
> > subsequent call to pCtrlCont->m_listSitesOrWnds.GetNext(pos) [at line 201]
> > triggers the assertion (then an MFC invalid argument exception).
> >
> > I've examined the relevant objects in the debugger and this is what I've
> > come up with:
> > 1) m_listSitesOrWnds is empty for the C_HomeView window.
> > 2) m_listSitesOrWnds is NOT empty fot the C_HtmlCtrl window. An entry is
> > added to the list during C_HtmlCtrl::OnCreate() when we call
> CreateControl()
> > to create the ActiveX control.
> >
> > The 6.x and 8.x implementations of _AfxFindNextMnem() are drastically
> > different, but I would assume that the new function should be checking for
> an
> > empty list before trying to get the 0-th element and generating the
> > assertion/exception.
> >
> > Has anyone else seen this behavior? Can anyone point me in a direction to
> > address the problem? We're several months into moving our product from VS
> 6
> > to VS 2005 and I'm pretty desperate.
> >
> > Thanks in advance for any help.
> >
> > Dylan Bourque
> > Lewis Computer Services
>
>
>
 | 
Pages: 1
Prev: PNG as a resource
Next: dynamic resizing