The following line of code from the CExtPaintManagerOffice2007_Impl::PaintGripper() method demonstrated on the screenshot returns a pointer to a CExtControlBar control bar contained by the floating mini frame window:
CExtControlBar * pBar = ((CExtMiniDockFrameWnd*)_pgd.m_pHelperSrc)->GetControlBarExt();
The
pBar variable can be some control bar or
NULL if it is not a Prof-UIS control bar. All control bars in Prof-UIS are derived from
CExtControlBar. Several years ago we supported MFC control bars. But we discontinued this support because they were less feature-rich and currently we have control bars of any well known type: toolbars, resizable bars, panel bars. If you are using Prof-UIS bars only, then you should not encounter this crash.
We tried to do the suggested experiment but we never faced any crashes. You can step into the
GetControlBarExt() method and find out which kind of bar
(pTempWnd) caused this problem:
CExtControlBar * CExtMiniDockFrameWnd::GetControlBarExt()
{
CControlBar * pTempWnd = GetControlBar();
if( pTempWnd == NULL )
return NULL;
if( !pTempWnd->IsKindOf( RUNTIME_CLASS(CExtControlBar) ) )
return NULL;
return reinterpret_cast < CExtControlBar * > ( pTempWnd );
}The
pTempWnd bar must never be
NULL because the mini frame window is always created before switching the control bar into the floating state. The control bar always exists before creating a floating mini frame window. If a mini frame is created successfully (as usually), then the next step is to put the control bar into a mini frame window using
SetParent() API. The mini frame window never becomes painted during these initialization actions and this means the
CExtPaintManagerOffice2007_Impl::PaintGripper() method never becomes invoked for a partially initialized mini frame window without a control bar window inside. But if you are using some low level thread hooks which are invoked during the creation of mini frame window and hook’s code causes delivering of painting messages to windows somehow, then potentially the mini frame window can become painted before it will be finally initialized. The commented code snippet on your screen shot can be safely uncommented, but indeed it should be never used.
In conclusion, it would be extremely helpful for us to reproduce this problem on any of our sample application in case of anything described above is not the real source of the problem.