Forum
Please
Log In
to post a new message or reply to an existing one. If you are not registered, please
register.
NOTE: Some forums may be read-only if you are not currently subscribed to
our technical support services.
|
Subject |
Author |
Date |
|
|
Alastair Watts
|
Jul 29, 2010 - 6:39 AM
|
CExtTreeGridWnd is slow with 35 columns * 2500 rows, this I accept so am considering changing grid controls & would like to know what kind of performance improvements to expect when using a CExtGridWnd instead. For example, when populating the entire grid from scratch. Thanks
|
|
|
Technical Support
|
Jul 29, 2010 - 6:49 AM
|
The CExtGridWnd plain grid control is much faster then the CExtTreeGridWnd tree grid control. The CExtGridWnd control does not need to manage tree data structures. It also supports the virtually cached mode which allows you to initialize only displayed grid cells. This is useful when the number of rows is unlimitedly high.
|
|
|
Alastair Watts
|
Jul 28, 2010 - 9:09 AM
|
|
|
|
|
Technical Support
|
Jul 28, 2010 - 9:23 AM
|
The __EGCS_READ_ONLY grid cell style makes any grid cell read only. The __EGCS_NO_INPLACE_CONTROL grid cell style disabled the in-place editing of any grid cell. Please apply these grid cell styles.
|
|
|
Robert Webb
|
Jul 28, 2010 - 2:17 AM
|
The new themes have two small 16x16 icons in the top left corner, rather than one larger 32x32 icon as before. I haven’t seen the matching version of Office, so could you tell me what icons are supposed to be used there? Currently we have the same icon in both places, and it’s confusing for users that the top left icon in one theme opens a different menu from the top left icon in the other theme. And if the buttons have the same icon they seem as if they should have the same function. I’m just not sure how to make it look sensible. One option would be to simply use the word "File" at the top of the file-menu (app-menu) instead of an icon. Is that easily done? Thanks, Rob.
|
|
|
Robert Webb
|
Jul 28, 2010 - 9:30 PM
|
|
|
|
|
Technical Support
|
Jul 29, 2010 - 3:46 AM
|
The final release version of Office 2010 displays File text on the ribbon file tab. The pre-release version displays icon. Now we support both modes of the ribbon file tab in all the Office 2010 themes. We send you an e-mail with the source code update download information.
|
|
|
Robert Webb
|
Jul 29, 2010 - 9:26 PM
|
Thanks. Just one problem. You draw the "File" text in black, which is very hard to see against the dark blue background. Have another look at the screenshot I linked to above. You’ll see that "File" is drawn in white and is much clearer. It is drawn in a different colour from the labels on other ribbon tabs. I hope you can fix this. Thanks, Rob.
|
|
|
Technical Support
|
Jul 30, 2010 - 9:16 AM
|
We reproduced this issue on Windows XP. It was OK on the later Windows versions. Please update the source code for the following two methods:
bool CExtPaintManagerOffice2010_Impl::Ribbon_FileButtonCalcLayout(
CDC & dc,
CExtNcFrameImpl * pExtNcFrameImpl,
CExtRibbonButtonFile * pFileTBB,
LPARAM lParam // = 0L
)
{
ASSERT_VALID( this );
ASSERT( dc.GetSafeHdc() != NULL );
ASSERT( pExtNcFrameImpl != NULL );
ASSERT_VALID( pFileTBB );
if( IsHighContrast() )
return CExtPaintManagerXP::Ribbon_FileButtonCalcLayout( dc, pExtNcFrameImpl, pFileTBB, lParam );
if( m_bmpArrRibbonFileButton.IsEmpty() )
return false;
CExtRibbonBar * pRibbonBar = DYNAMIC_DOWNCAST( CExtRibbonBar, pFileTBB->GetBar() );
if( pRibbonBar == NULL )
return false;
ASSERT_VALID( pRibbonBar );
INT nTextBasedWidth = 0;
if( pRibbonBar->m_bFileTabButtonDisplaysText )
{
CExtSafeString sText = pFileTBB->GetText();
if( ! sText.IsEmpty() )
{
CRect rcMeasure( 0, 0, 0, 0 );
CFont * pFont = pRibbonBar->OnGetToolbarFont( false, false, pFileTBB );
ASSERT( pFont->GetSafeHandle() != NULL );
CFont * pOldFont = dc.SelectObject( pFont );
INT nOldBkMode = dc.SetBkMode( TRANSPARENT );
COLORREF clrText = RGB(0x0FF,0x0FF,0x0FF);
COLORREF clrOldTextColor = dc.SetTextColor( clrText );
if( g_PaintManager.m_bIsWinVistaOrLater )
{
CExtUxTheme::__EXT_UX_DTTOPTS dto = { sizeof(CExtUxTheme::__EXT_UX_DTTOPTS) };
dto.dwFlags = __EXT_UX_DTT_COMPOSITED | __EXT_UX_DTT_TEXTCOLOR;
dto.crText = clrText;
CExtRichContentLayout::stat_DrawText(
dc.m_hDC, LPCTSTR(sText), &rcMeasure,
DT_SINGLELINE|DT_CENTER|DT_VCENTER|DT_NOPREFIX|DT_END_ELLIPSIS|DT_NOCLIP|DT_CALCRECT /*| ( bRTL ? DT_RTLREADING : 0 )*/, 0,
pRibbonBar->m_hWnd, VSCLASS_WINDOW, /*__EXT_UX_OTD_NONCLIENT*/ 0, 0, 0, &dto
);
}
else
CExtRichContentLayout::stat_DrawText(
dc.m_hDC, LPCTSTR(sText), &rcMeasure,
DT_SINGLELINE|DT_CENTER|DT_VCENTER|DT_NOPREFIX|DT_END_ELLIPSIS|DT_NOCLIP|DT_CALCRECT /*| ( bRTL ? DT_RTLREADING : 0 )*/, 0
);
dc.SelectObject( pOldFont );
dc.SetTextColor( clrOldTextColor );
dc.SetBkMode( nOldBkMode );
dc.SelectObject( pOldFont );
nTextBasedWidth = rcMeasure.Width() + 10;
} // if( ! sText.IsEmpty() )
}
CSize _sizeTBB( m_bmpArrRibbonFileButton.GetSize().cx, m_nRibbonFileButtonHeight - 1 );
_sizeTBB.cx = UiScalingDo( _sizeTBB.cx, __EUIST_X );
_sizeTBB.cy = UiScalingDo( _sizeTBB.cy, __EUIST_Y );
INT nPageIndex, nPageCount = pRibbonBar->RibbonTabPageButton_GetCount();
for( nPageIndex = 0; nPageIndex < nPageCount; nPageIndex ++ )
{
CExtRibbonButtonTabPage * pTabPageTBB = pRibbonBar->RibbonTabPageButton_GetAt( nPageIndex );
ASSERT( pTabPageTBB );
if( ( pTabPageTBB->GetStyle() & TBBS_HIDDEN ) != 0 )
continue;
if( ! pTabPageTBB->IsVisible() )
continue;
CSize sizeTabPageButton = pTabPageTBB->Size();
_sizeTBB.cy = max( _sizeTBB.cy, sizeTabPageButton.cy );
break;
} // for( . . .
if( nTextBasedWidth > 0 )
_sizeTBB.cx = max( _sizeTBB.cx, nTextBasedWidth );
INT nTabLineHeight = pRibbonBar->RibbonLayout_GetTabLineHeight();
INT nTopBorderHeight = 0;
INT nFrameCaptionHeight = pRibbonBar->RibbonLayout_GetFrameCaptionHeight( &nTopBorderHeight );
INT nHeightAtTheTop = nTabLineHeight + nFrameCaptionHeight;
INT nBottomLineHeight = pRibbonBar->RibbonLayout_GetBottomLineHeight();
CRect rcClient;
pRibbonBar->GetClientRect( &rcClient );
CRect rcPageBk = rcClient;
rcPageBk.top += nHeightAtTheTop;
rcPageBk.bottom -= nBottomLineHeight;
if( pRibbonBar->RibbonLayout_IsFrameIntegrationEnabled()
&& (! pRibbonBar->RibbonLayout_IsDwmCaptionIntegration() )
)
rcPageBk.top += nFrameCaptionHeight + nTopBorderHeight;
CRect rcTabLine(
rcPageBk.left,
rcPageBk.top - nTabLineHeight,
rcPageBk.right,
rcPageBk.top
);
pRibbonBar->RibbonLayout_AdjustTabLineRect( rcTabLine );
INT nHorzOffset = UiScalingDo( 2, __EUIST_X );
CRect rcTBB( nHorzOffset, rcTabLine.bottom - _sizeTBB.cy, nHorzOffset + _sizeTBB.cx, rcTabLine.bottom );
pFileTBB->Size( _sizeTBB );
pFileTBB->SetRect( rcTBB );
return true;
}
bool CExtPaintManagerOffice2007_Impl::Ribbon_FileButtonPaint(
CDC & dc,
CExtRibbonButtonFile * pFileTBB,
LPARAM lParam // = 0L
)
{
ASSERT_VALID( this );
ASSERT( dc.GetSafeHdc() != NULL );
ASSERT_VALID( pFileTBB );
if( IsHighContrast() )
return CExtPaintManagerXP::Ribbon_FileButtonPaint( dc, pFileTBB, lParam );
if( m_bmpArrRibbonFileButton.IsEmpty() )
return false;
CRect rcTBB = *pFileTBB;
if( ! dc.RectVisible( &rcTBB ) )
return true;
CExtRibbonBar * pRibbonBar = DYNAMIC_DOWNCAST( CExtRibbonBar, pFileTBB->GetBar() );
if( pRibbonBar == NULL )
return false;
INT nBmpIndex = 0;
CExtCmdIcon::e_paint_type_t ePT = CExtCmdIcon::__PAINT_DISABLED;
bool bSelTrackingMode = false;
const CExtToolControlBar * pToolBar = pFileTBB->GetBar();
if( pToolBar != NULL )
{
CExtMenuControlBar * pMenuBar = DYNAMIC_DOWNCAST( CExtMenuControlBar, pToolBar );
if( pMenuBar != NULL
&& pMenuBar->IsMenuBarTracking()
)
{
int nFlatTrackingIndex = pMenuBar->_FlatTrackingIndexGet();
if( nFlatTrackingIndex >= 0 )
{
int nIndexOfTBB = pMenuBar->_GetIndexOf( pFileTBB );
if( nFlatTrackingIndex == nIndexOfTBB )
bSelTrackingMode = true;
}
}
}
if( bSelTrackingMode )
{
nBmpIndex = 1;
ePT = CExtCmdIcon::__PAINT_HOVER;
}
else if( pFileTBB->IsEnabled() )
{
if( pFileTBB->IsPressed() )
{
nBmpIndex = 2;
ePT = CExtCmdIcon::__PAINT_PRESSED;
}
else if( pFileTBB->IsHover() )
{
nBmpIndex = 1;
ePT = CExtCmdIcon::__PAINT_HOVER;
}
else
{
ePT = CExtCmdIcon::__PAINT_NORMAL;
}
}
bool bRTL = false, bDwmMode = pRibbonBar->RibbonLayout_IsDwmCaptionIntegration();
if( (dc.GetLayout()&LAYOUT_RTL) == LAYOUT_RTL )
bRTL = true;
DWORD dwOldRTF = 0;
CRect rcSrc( 0, 0, m_bmpArrRibbonFileButton.GetSize().cx, m_nRibbonFileButtonHeight );
rcSrc.OffsetRect( 0, nBmpIndex * m_nRibbonFileButtonHeight );
CRect rcPadding( 0, 0, 0, 0 );
bool bTextOverTabMode = false;
if( pRibbonBar->m_bFileTabButtonDisplaysText && IsKindOf(RUNTIME_CLASS(CExtPaintManagerOffice2010_Impl)) )
{
bTextOverTabMode = true;
rcPadding.SetRect( 5, 3, 5, 3 );
}
if( (!bTextOverTabMode) && rcSrc.Size() != rcTBB.Size() )
{
CExtBitmap _bmp;
_bmp.FromBitmap( m_bmpArrRibbonFileButton, rcSrc );
CRect _rcSrc( 0, 0, rcTBB.Width(), rcTBB.Height() );
CExtBitmap::Filter _f( CExtBitmap::Filter::gaussian );
_f.FilterWidthSet( 2.0 );
_bmp.Scale( rcTBB.Width(), rcTBB.Height(), _f );
if( bDwmMode && bRTL )
{
dwOldRTF = _bmp.RunTimeFlagsGet();
_bmp.RunTimeFlagsSet( dwOldRTF | __EXT_BMP_FLAG_NO_RTL_DETECTION );
}
_bmp.AlphaBlendSkinParts(
dc.m_hDC,
rcTBB,
_rcSrc,
rcPadding,
CExtBitmap::__EDM_STRETCH,
true,
true
);
if( bDwmMode && bRTL )
{
_bmp.RunTimeFlagsSet( dwOldRTF );
}
} // if( (!bTextOverTabMode) && rcSrc.Size() != rcTBB.Size() )
else
{
if( bDwmMode && bRTL )
{
dwOldRTF = m_bmpArrRibbonFileButton.RunTimeFlagsGet();
m_bmpArrRibbonFileButton.RunTimeFlagsSet( dwOldRTF | __EXT_BMP_FLAG_NO_RTL_DETECTION );
}
m_bmpArrRibbonFileButton.AlphaBlendSkinParts(
dc.m_hDC,
rcTBB,
rcSrc,
rcPadding,
CExtBitmap::__EDM_STRETCH,
true,
true
);
if( bDwmMode && bRTL )
{
m_bmpArrRibbonFileButton.RunTimeFlagsSet( dwOldRTF );
}
if( bTextOverTabMode )
{
CExtSafeString sText = pFileTBB->GetText();
if( ! sText.IsEmpty() )
{
CFont * pFont = pRibbonBar->OnGetToolbarFont( false, false, pFileTBB );
ASSERT( pFont->GetSafeHandle() != NULL );
CFont * pOldFont = dc.SelectObject( pFont );
INT nOldBkMode = dc.SetBkMode( TRANSPARENT );
COLORREF clrText = RGB(0x0FF,0x0FF,0x0FF);
COLORREF clrOldTextColor = dc.SetTextColor( clrText );
rcTBB.DeflateRect( &rcPadding );
if( g_PaintManager.m_bIsWinVistaOrLater )
{
CExtUxTheme::__EXT_UX_DTTOPTS dto = { sizeof(CExtUxTheme::__EXT_UX_DTTOPTS) };
dto.dwFlags = __EXT_UX_DTT_COMPOSITED | __EXT_UX_DTT_TEXTCOLOR;
dto.crText = clrText;
CExtRichContentLayout::stat_DrawText(
dc.m_hDC, LPCTSTR(sText), &rcTBB,
DT_SINGLELINE|DT_CENTER|DT_VCENTER|DT_NOPREFIX|DT_END_ELLIPSIS /*| ( bRTL ? DT_RTLREADING : 0 )*/, 0,
pRibbonBar->m_hWnd, VSCLASS_WINDOW, /*__EXT_UX_OTD_NONCLIENT*/ 0, 0, 0, &dto
);
}
else
CExtRichContentLayout::stat_DrawText(
dc.m_hDC, LPCTSTR(sText), &rcTBB,
DT_SINGLELINE|DT_CENTER|DT_VCENTER|DT_NOPREFIX|DT_END_ELLIPSIS /*| ( bRTL ? DT_RTLREADING : 0 )*/, 0
);
dc.SelectObject( pOldFont );
dc.SetTextColor( clrOldTextColor );
dc.SetBkMode( nOldBkMode );
dc.SelectObject( pOldFont );
} // if( ! sText.IsEmpty() )
}
} // else from if( (!bTextOverTabMode) && rcSrc.Size() != rcTBB.Size() );
if( ( ! bTextOverTabMode ) && ( ! pFileTBB->m_iconForLargeMode.IsEmpty() ) )
{
CRect rc( rcTBB.TopLeft(), pFileTBB->m_iconForLargeMode.GetSize() );
rc.OffsetRect(
( rcTBB.Width() - rc.Width() ) / 2,
( rcTBB.Height() - rc.Height() ) / 2
);
CExtBitmap & _bmp = pFileTBB->m_iconForLargeMode.GetBitmap( ePT, this );
if( bDwmMode && bRTL )
{
dwOldRTF = _bmp.RunTimeFlagsGet();
_bmp.RunTimeFlagsSet( dwOldRTF | __EXT_BMP_FLAG_NO_RTL_DETECTION );
}
if( bRTL )
{
CExtBitmap _bmp2 = _bmp;
_bmp2.FlipHorizontal();
if( ! _bmp2.IsEmpty() )
{
CSize _size = _bmp2.GetSize();
_bmp2.AlphaBlend(
dc.m_hDC,
rc.left,
rc.top,
rc.Width(),
rc.Height(),
0,
0,
rc.Width(),
rc.Height()
);
}
}
else
{
pFileTBB->m_iconForLargeMode.Paint(
this,
dc.m_hDC,
rc,
ePT
);
}
if( bDwmMode && bRTL )
{
_bmp.RunTimeFlagsSet( dwOldRTF );
}
} // if( ( ! bTextOverTabMode ) && ( ! pFileTBB->m_iconForLargeMode.IsEmpty() ) )
return true;
}
|
|
|
Technical Support
|
Jul 28, 2010 - 9:54 AM
|
Implemented. Please drop us an e-mail and we will provide you with the source code update.
|
|
|
Technical Support
|
Jul 28, 2010 - 3:00 AM
|
Please let us remind you, we already discussed implementation of different size icons in the ribbon file button here: http://www.prof-uis.com/prof-uis/tech-support/support-forum/main-icon-in-2010-themes-67320.aspx#67332 We had to use the 32x32 icons in Office 2007 themes because the ribbon file button is big and round. We had to use the 16x16 icons in Office 2010 themes because the ribbon file button is small and looks like tab item. You can use the same 16x16 icon in the Office 2007 themes but they will not have a good visual appearance. Besides the round file button in styles 2007 is light when the ribbon file buttons’ tab item in Office 2010 themes is dark. We can add support for the File text instead of small 16x16 icon. This will let you avoid painting small 16x16 icon for your app. Please give us 1..2 days.
|
|
|
Kevin Murray
|
Jul 26, 2010 - 11:43 AM
|
This is interesting, but I have reproduced it in the MDI_DynamicBars sample. First, some history. When we switched from our previous GUI library to Prof-UIS we lost one feature of the docking system. Namely, when a window was in MDI mode, the old system had on the docking menu an extra popup menu entry labeled "Dock To" with the choices Left, Right, Top, Bottom. Only available in MDI mode, it allowed the user the ability to redock the window to the side they wanted, not simply back to where it was docked before being made into an MDI window. I was tasked with adding this functionality into our new Prof-UIS driven docking system. I did, but it lead to the discovery of a very interesting bug. Now, to reproduce this is MDI_DynamicBars sample, add the following methods to the CSimpleControlBar class found in MainFrm.h:
LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam ){ LRESULT rc = __super::WindowProc( message, wParam, lParam ); switch( message ) { case WM_COMMAND: { UINT nCmdID = (UINT)wParam; if( (nCmdID >= 4001) && (nCmdID <= 4004) ) { DockToSide( nCmdID ); } } break; } return rc; } virtual bool OnInitDbsMenu( CExtPopupMenuWnd * pPopup, HWND hWndTrack, CObject * pHelperSrc, LPARAM lParamHelper = 0 ) { bool rc = CExtDynamicControlBar::OnInitDbsMenu( pPopup, hWndTrack, pHelperSrc, lParamHelper ); if( (rc == true) && (BarStateGet() == CExtDynamicControlBar::__EDBS_DOCUMENT) ) { CExtPopupMenuWnd* pmenu = new CExtPopupMenuWnd(); pmenu->CreatePopupMenu( m_hWnd ); if( g_CmdManager->CmdIsRegistered( g_CmdManager->ProfileNameFromWnd( m_hWnd ), 4001 ) == false ) { CExtCmdItem* pItem; pItem = g_CmdManager->CmdAllocPtr( g_CmdManager->ProfileNameFromWnd( m_hWnd ), 4001 ); pItem->m_sMenuText = "Left"; pItem->StateEnable(); pItem = g_CmdManager->CmdAllocPtr( g_CmdManager->ProfileNameFromWnd( m_hWnd ), 4002 ); pItem->m_sMenuText = "Top"; pItem->StateEnable(); pItem = g_CmdManager->CmdAllocPtr( g_CmdManager->ProfileNameFromWnd( m_hWnd ), 4003 ); pItem->m_sMenuText = "Right"; pItem->StateEnable(); pItem = g_CmdManager->CmdAllocPtr( g_CmdManager->ProfileNameFromWnd( m_hWnd ), 4004 ); pItem->m_sMenuText = "Bottom"; pItem->StateEnable(); } pmenu->ItemInsert( 4001 ); pmenu->ItemInsert( 4002 ); pmenu->ItemInsert( 4003 ); pmenu->ItemInsert( 4004 ); pmenu->ItemGetInfo( 0 ).SetNoCmdUI( true ); pmenu->ItemGetInfo( 1 ).SetNoCmdUI( true ); pmenu->ItemGetInfo( 2 ).SetNoCmdUI( true ); pmenu->ItemGetInfo( 3 ).SetNoCmdUI( true ); pPopup->ItemInsertSpecPopup( pmenu, -1, "Dock to" ); } return rc; } void DockToSide( int nSide ) { UINT uiSide = AFX_IDW_DOCKBAR_LEFT; switch( nSide ) { case 4001: uiSide = AFX_IDW_DOCKBAR_LEFT; break; case 4002: uiSide = AFX_IDW_DOCKBAR_TOP; break; case 4003: uiSide = AFX_IDW_DOCKBAR_RIGHT; break; case 4004: uiSide = AFX_IDW_DOCKBAR_BOTTOM; break; } OnMoveChildToBar(); _AffixmentSafeClearOuter(); m_pDockSite->DockControlBar( this, uiSide ); m_pDockSite->ShowControlBar( this, TRUE, FALSE ); m_pDockSite->RecalcLayout(); }
Now this code doesn’t do a lot of error checking or optimization, but it will serve its purpose of demonstrating the bug. Run the app and close all dynamic bars (even the auto-hidden persistent bars). Now, using the menu, open three of the dynamic bars. Dock them to the left, each one docking under the previous by dragging to the appropriate dock marker on the windows. Now on the bottom most window, select Tabbed Document from the menu. It will become an MDI window. Right click its menu bar and select Dock to and pick Right. The window will dock to the right, only two issues now exist: 1) It docks on the outer most circle. Any attempts to dock to an inner circle will result in problem number 2 (below) immediately. 2) If you drag the dynamic bar off the application (or change the DockToSide method to dock to an inner circle), the other two windows still docked on the left stack on top of each other so that only one is visible, and lots of empty space below it. This seemingly can only be reproduced with three or more windows. If you attempt to close the application after the aforementioned problem happens, it will ASSERT and crash and such. I have tried changing to the DockToSide code in various ways with various combinations of dock calls, to no avail. Is there a way for me to properly implement this feature and avoid the bug? Is there perhaps a way to change the Prof-UIS library to avoid the bug? Any help greatly appreciated. K.
|
|
|
Kevin Murray
|
Jul 27, 2010 - 12:24 PM
|
That doesn’t work. The problem crops up immediately upon docking the bar to the right side. K.
|
|
|
Technical Support
|
Jul 28, 2010 - 2:22 AM
|
|
|
|
|
Kevin Murray
|
Jul 28, 2010 - 11:19 AM
|
I tried your project, and get the same results. I have emailed two screenshots to support. The first, DynamicBarIssue_Start.jpg, shows how I stack the bars. I then make DynamicBar2 into a tabbed document, then DyanamicBarIssue_AfterDocking.jpg shows what happens when I pick "Dock To --> Right" using your version of the code. This is the same result I saw if I tried moving Bar 2 after docking it. I should also mention if you exit the application in this sate, so it saves the bar states, then reload, you get an ASSERT on load, which you can ignore, then the app loads with the bars where you would expect them to be. K.
|
|
|
Kevin Murray
|
Jul 28, 2010 - 11:20 AM
|
And for what it is worth, I’m on Vista 32-bit. K.
|
|
|
Technical Support
|
Jul 29, 2010 - 3:53 AM
|
This is not possible. The CExtControlBar::DockControlBarInnerOuter() always docks one control bar into one new row/column near the outer frame side or into the inner frame side. There are no conflicts with other bars. The new row/column of bars is organized and it contain only one bar. We cannot reproduce the incorrect layout demonstrated on the screen shots you sent us. Please provide us with exact step-by-step description of how to reproduce the incorrect bar layout? We suspect it may depend on the bar states restored at app startup. The bar states can be incorrect on your computer because the previous version of this test app performed incorrect bar redocking.
|
|
|
Kevin Murray
|
Jul 29, 2010 - 10:56 AM
|
I went through my registry and removed all references to MDI_DynamicBars* to remove the state information (I hope anyway -- it does make it start in the default state). I start the application. It comes up maximized with lots of windows open. I close every Dynamic Bar window via its X button, both docked and in the MDI area, and I close the Persistent bar that is auto-hidden on the left by mousing over it and hitting the X. I leave the MDIDOC1 window and the toolbars/menubar open. I use the View menu, go to Dynamic Resizable Bars, and select Dynamic Bar 0. I drag it from its position to the dock marker at the left of the application. I then drag the sizing bar to make it wider as it docks far too narrowly. I go back to View --> Dynamic Resiable bars and pick Dynamic Bar 1. I drag it over Dynamic Bar 0 and drop it on Bar 0’s bottom dock marker. I go back to the menu, pick Dynamic Bar 2, drag it tfrom its default location o Dynamic Bar 1’s bottom dock marker. I then click on the down arrow button on Dynamic Bar 2’s caption bar, and select Tabbed Document from the menu. It becomes an MDI window. I then go to Dynamic Bar 2’s title bar, right click, and select Dock to --> Right on the menu. The result is what I sent in the screen shot. K.
|
|
|
Technical Support
|
Jul 30, 2010 - 9:14 AM
|
We reproduced this issue. We have an alpha version of the fix for it. Please drop us an e-mail to the support mail box at this web site so we will provide you with the source code update.
|
|
|
Technical Support
|
Jul 27, 2010 - 10:35 AM
|
Thank you for the sample code. The problem is hidden in the DockToSide() method. It does not change the state of the dynamic resizable control bar from document to docked mode. It uses CFrameWnd::DockControlBar() method instead of the CExtControlBar::DockControlBarInnerOuter() method. Here is the correct version:
void DockToSide( int nSide )
{
UINT uiSide = AFX_IDW_DOCKBAR_LEFT;
switch( nSide )
{
case 4001: uiSide = AFX_IDW_DOCKBAR_LEFT; break;
case 4002: uiSide = AFX_IDW_DOCKBAR_TOP; break;
case 4003: uiSide = AFX_IDW_DOCKBAR_RIGHT; break;
case 4004: uiSide = AFX_IDW_DOCKBAR_BOTTOM; break;
}
VERIFY( BarStateSet( CExtDynamicControlBar::__EDBS_DOCKED, false ) );
DelayShow( TRUE );
DockControlBarInnerOuter( uiSide, true, m_pDockSite );
}
|
|
|
Alastair Watts
|
Jul 26, 2010 - 7:01 AM
|
Ideally I’d like to extend the existing CExtGridCellHeaderFilter popup menu to allow for the display of additional grid columns, otherwise I’m happy to display a new popup. How do I create the list of items with check-boxes? Thanks
|
|
|
Technical Support
|
Jul 26, 2010 - 10:03 AM
|
The CExtPopupListBoxMenuWnd class implements popup menu containing list box control instead of menu items. This popup menu works via the set of the CExtPopupListBoxMenuWnd::m_pCb*** callback function pointers. I.e. check boxes are implemented as custom drawn part of list box items.
|
|
|
Eric guez
|
Jul 23, 2010 - 12:26 AM
|
Hi !
I use a CExtNCSB<CExtListCtrl> to have skinned scrollbars (in my example I use blackdiamond).
Is it possible to use 2 different scrollbar width depending on the normal/pressend/... status ? My goal is to have a very small scroll bar (to indicate position) while not using it.
Thanks
|
|
|
Technical Support
|
Jul 23, 2010 - 3:48 AM
|
Thank you for the interesting question. We would like to ask you to tell us where did you saw such dynamic size scroll bars? By default all the scrollable common controls use the built-in window scroll bars which are parts of window non-client area. These scroll bars are not the scroll bar windows. It’s not possible to re-paint the non-client area based scroll bars via handling the WM_NCPAINT standard message. Windows often draws the non-client window scroll bars without sending this message. But, the CExtNCSB template class skins these scroll bars. It simply creates the horizontal and vertical CExtScrollBar windows on the top of the non-client area window which requires the scroll bar skinning. The CExtNCSB template class synchronizes the scrolling parameters of the CExtScrollBar windows with the scrolling parameters of the non-client area scroll bars. That’s why the scroll bar skinning is possible with Prof-UIS. We can make the CExtScrollBar windows on the top of your list control smaller. But we cannot make the list control’s non-client area scroll bars smaller because this will damage the non-client area parts of list control like borders. The task you requested can be implemented with controls written from scratch like Prof-UIS grid controls.
|
|
|
Eric guez
|
Jul 27, 2010 - 10:24 AM
|
I’ve not seen this anywhere.
I was using my iphone, and iphone UI never shows srollbars until you scroll.
I dont think this behaviour is good (since I always need a scroll indicator to evaluate my list size and the actual scroll position). But resizing scrollbar while not using it may be a good idea.
|
|
|
Eric guez
|
Jul 27, 2010 - 10:26 AM
|
|
|
|
|
Technical Support
|
Jul 28, 2010 - 5:59 AM
|
The article referred in your message demonstrates the scroll bar usage similar to that implemented by the CExtNCSB template class in Prof-UIS. But its author just implemented support for custom scroll bar width. This can be acceptable for the CListBox common control where all the items are just a strings organized into the simple column. Besides, the implementation of the custom width scroll bar looks like incompatible with list box items containing long text. This approach is not acceptable for the most of other controls. The scroll bar with large width will cover items of the CListCtrl control. I.e. the non client area of the CListCtrl control should be recomputed and its themed borders will be damaged. This means the variable size scroll bars can be implemented only with windows written from scratch. We can assume your question is a feature request for coding our list view control.
|
|
|
Kevin Murray
|
Jul 22, 2010 - 3:33 PM
|
I have been able to reproduce this in the MDI-DynamicBars sample in 2.90, but it does not happen in 2.85 sample of the same name. Basically if you have a Dynamic Bar as an MDI window ("Tabbed Document" in the bar menu), then you select "Floating" from the menu while it is in MDI mode, the bar is floated and invisible. I know it is there because 1) Spy++ shows the window in its list, but shows it as not visible, and 2) if you exit the application so it saves the bar states, then restart it, the window will be visible and floating. K.
|
|
|
Technical Support
|
Jul 23, 2010 - 6:00 AM
|
Thank you for reporting this issue. To fix it, please update the source code for the following method:
bool CExtDynamicControlBar::BarStateSet(
CExtDynamicControlBar::eDynamicBarState_t eDBS,
bool bShow
)
{
ASSERT_VALID( this );
ASSERT_VALID( m_pDockSite );
m_eHelperSwitchingDBS = eDBS;
m_bHelperSwitchingIntoVisibleState = bShow;
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
if( eDBS == __EDBS_AUTO_HIDDEN && (!bShow) )
eDBS = __EDBS_DOCKED;
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
CExtDynamicBarSite * pDBS = GetBarSite();
if( pDBS == NULL )
return false;
CExtDynamicBarSite::eDetectedUiType_t eDUIT = pDBS->GetDetectedUiType();
switch( eDBS )
{
case __EDBS_FLOATING:
{
m_bAppearInDockSiteControlBarPopupMenu = true;
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
if( AutoHideModeGet() )
AutoHideModeSet( false, false, false, true );
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
bool bFloating = IsFloating();
CExtMiniDockFrameWnd * pOldMiniDockFrameWndToHide = NULL;
HWND hWndOldMiniDockFrameWndToHide = NULL;
bool bHideOldFrame = false;
CFrameWnd * pParentFrame = GetParentFrame();
ASSERT( pParentFrame != NULL );
if( ! bFloating )
{
pOldMiniDockFrameWndToHide = DYNAMIC_DOWNCAST( CExtMiniDockFrameWnd, pParentFrame );
if( pOldMiniDockFrameWndToHide != NULL )
{
hWndOldMiniDockFrameWndToHide = pOldMiniDockFrameWndToHide->GetSafeHwnd();
if( pOldMiniDockFrameWndToHide->_GetSingleVisibleBar() != this )
pOldMiniDockFrameWndToHide = NULL;
else
bHideOldFrame = true;
}
}
else
{
OnMoveChildToBar();
DelayShow( bShow ? TRUE : FALSE );
if( (! bShow ) && IsVisible()
|| bShow && (! IsVisible() )
)
OnFrameBarCheckCmd( true ); // show/hide me
GetParentFrame()->RecalcLayout();
break;
}
OnMoveChildToBar();
if( ! bFloating )
FloatControlBar();
CControlBar::DelayShow( bShow ? TRUE : FALSE );
if( hWndOldMiniDockFrameWndToHide != NULL
&& pOldMiniDockFrameWndToHide == NULL
&& ::IsWindow( hWndOldMiniDockFrameWndToHide )
)
{
bHideOldFrame = false;
pOldMiniDockFrameWndToHide = DYNAMIC_DOWNCAST( CExtMiniDockFrameWnd, CWnd::FromHandlePermanent( ( hWndOldMiniDockFrameWndToHide ) ) );
}
if( pOldMiniDockFrameWndToHide != NULL )
{
if( bHideOldFrame )
pOldMiniDockFrameWndToHide->ShowWindow( SW_HIDE );
CWnd * pWnd = pOldMiniDockFrameWndToHide->GetDlgItem( AFX_IDW_DOCKBAR_FLOAT );
if( pWnd != NULL )
{
pOldMiniDockFrameWndToHide->RepositionBars( 0, 0xFFFF, AFX_IDW_DOCKBAR_FLOAT );
pWnd = pWnd->GetWindow( GW_CHILD );
if( pWnd != NULL )
{
CExtDynControlBar * pDynControlBar = DYNAMIC_DOWNCAST( CExtDynControlBar, pWnd );
if( pDynControlBar != NULL )
{
if( pDynControlBar->m_pWndDynDocker != NULL )
pDynControlBar->m_pWndDynDocker->OnDynamicLayoutOptimize();
}
}
}
pOldMiniDockFrameWndToHide->RepositionBars( 0, 0xFFFF, AFX_IDW_DOCKBAR_FLOAT );
}
if( (! bShow ) && IsVisible()
|| bShow && (! IsVisible() )
)
OnFrameBarCheckCmd( true ); // show/hide me
CFrameWnd * pWndParentFrame = GetParentFrame();
ASSERT_VALID( pWndParentFrame );
ASSERT_KINDOF( CExtMiniDockFrameWnd, pWndParentFrame );
if( bShow && ( pWndParentFrame->GetStyle() & WS_VISIBLE ) == 0 )
pWndParentFrame->ShowWindow( SW_SHOWNA );
else if( (!bShow) && ( pWndParentFrame->GetStyle() & WS_VISIBLE ) != 0 )
pWndParentFrame->ShowWindow( SW_HIDE );
if( bShow )
pWndParentFrame->RecalcLayout();
}
break;
case __EDBS_DOCKED:
{
if( IsFloating() )
{
m_bAppearInDockSiteControlBarPopupMenu = true;
OnMoveChildToBar();
DelayShow( bShow ? TRUE : FALSE );
if( (! bShow ) && IsVisible()
|| bShow && (! IsVisible() )
)
OnFrameBarCheckCmd( true ); // show/hide me
GetParentFrame()->RecalcLayout();
break;
}
CRect rcFrameWnd( 0, 0, 0, 0 );
CFrameWnd * pWndFrame = GetParentFrame();
CExtMiniDockFrameWnd * pWndMiniFrame = NULL;
CExtDynControlBar * pDynControlBar = NULL;
if( pWndFrame != NULL )
{
pWndFrame->GetWindowRect( &rcFrameWnd );
pWndMiniFrame = DYNAMIC_DOWNCAST( CExtMiniDockFrameWnd, pWndFrame );
if( pWndMiniFrame != NULL )
{
pWndMiniFrame->ModifyStyle( FWS_SNAPTOBARS, 0 );
CWnd * pWnd = pWndMiniFrame->GetDlgItem( AFX_IDW_DOCKBAR_FLOAT );
if( pWnd != NULL )
{
pWnd = pWnd->GetWindow( GW_CHILD );
if( pWnd != NULL )
pDynControlBar = DYNAMIC_DOWNCAST( CExtDynControlBar, pWnd );
}
}
}
m_bAppearInDockSiteControlBarPopupMenu = true;
OnMoveChildToBar();
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
if( AutoHideModeGet() )
{
AutoHideModeSet( false, false, true, true );
if( bShow )
OnFrameBarCheckCmd( false ); // show me
} // if( AutoHideModeGet() )
else
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
{
if( bShow )
m_eDBS = eDBS; // for making OnQueryVisibilityInContainerTabs() returning true
if( (! bShow ) && IsVisible()
|| bShow && (! IsVisible() )
)
OnFrameBarCheckCmd( true ); // show/hide me
if( pWndMiniFrame != NULL )
{
CWnd * pWnd = pWndMiniFrame->GetDlgItem( AFX_IDW_DOCKBAR_FLOAT );
if( pWnd != NULL )
{
pWndFrame->MoveWindow( &rcFrameWnd );
pWndMiniFrame->RepositionBars( 0, 0xFFFF, AFX_IDW_DOCKBAR_FLOAT );
if( pDynControlBar != NULL )
pDynControlBar->OnRepositionSingleChild();
}
pWndFrame->RecalcLayout();
}
} // else from if( AutoHideModeGet() )
}
break;
case __EDBS_DOCUMENT:
if( OnQueryChildHWND() == NULL )
{
ASSERT( FALSE );
return false;
} // if( OnQueryChildHWND() == NULL )
if( eDUIT == CExtDynamicBarSite::__EDUIT_UNSUPPORTED_ENVIRONMENT )
{
ASSERT( FALSE );
return false;
} // if( OnQueryChildHWND() == NULL )
m_bAppearInDockSiteControlBarPopupMenu = false;
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
if( AutoHideModeGet() )
AutoHideModeSet( false, false, false, true );
else
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
if( IsVisible() )
{
OnFrameBarCheckCmd( true ); // hide me
GetParentFrame()->RecalcLayout();
}
if( bShow )
OnMoveChildToDocument();
else
OnMoveChildToBar();
break;
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
case __EDBS_AUTO_HIDDEN:
m_bAppearInDockSiteControlBarPopupMenu = true;
ASSERT( bShow );
if( ! AutoHideModeGet() )
{
OnMoveChildToBar();
if( IsFloating()
|| GetParentFrame() != m_pDockSite
)
{
VERIFY(
DockControlBarInnerOuter(
AFX_IDW_DOCKBAR_LEFT,
false,
m_pDockSite,
false
)
);
}
VERIFY(
AutoHideModeSet(
true,
false,
true,
false
)
);
} // if( ! AutoHideModeGet() )
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
break;
#ifdef _DEBUG
default:
{
ASSERT( FALSE );
}
break;
#endif // _DEBUG
} //switch( eDBS )
m_eDBS = eDBS;
if( bShow )
m_dwAdditionalStateFlags &= ~__EASF_INVISIBLE;
else
m_dwAdditionalStateFlags |= __EASF_INVISIBLE;
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
if( eDBS == __EDBS_AUTO_HIDDEN )
{
CExtDockDynTabBar * pDynDockBar =
DYNAMIC_DOWNCAST(
CExtDockDynTabBar,
GetParent()
);
if( pDynDockBar != NULL )
{
CExtDynTabControlBar * pTabbedBar =
DYNAMIC_DOWNCAST(
CExtDynTabControlBar,
pDynDockBar->GetParent()
);
LONG nPos, nCount = pTabbedBar->GetSwitcherItemCount();
for( nPos = 0; nPos < nCount; nPos++ )
{
CExtControlBar * pContainedBar = pTabbedBar->GetBarAt( nPos, true );
CExtDynamicControlBar * pDynamicBar = DYNAMIC_DOWNCAST( CExtDynamicControlBar, pContainedBar );
if( pDynamicBar != NULL )
pDynamicBar->m_eDBS = eDBS;
} // for( nPos = 0; nPos < nCount; nPos++ )
} // if( pDynDockBar != NULL )
}
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
return true;
}
|
|
|
Alastair Watts
|
Jul 22, 2010 - 8:10 AM
|
On my Intel e8400 running @ 3Ghz sorting 10 columns * 2000 items takes ten seconds. Is there anything that can be done to considerably improve performance here?
|
|
|
Alastair Watts
|
Jul 26, 2010 - 4:27 AM
|
This is in Release mode. It’s faster for me to read the database into memory, sort the memory & re-build the grid ... this can’t be right???
|
|
|
Technical Support
|
Jul 26, 2010 - 10:01 AM
|
This is not exactly similar to Release. The debugging information is on.
|
|
|
Technical Support
|
Jul 22, 2010 - 8:18 AM
|
The grid controls in Debug version are much slower then in Release due to heavy assertions everywhere. Please take a look at the beginning of the .../Prof-UIS/Include/ExtGridWnd.h file and check the following: 1) The following lines should be commented:
// #if (defined _DEBUG)
// #define __EXT_DEBUG_HEAVY_CHECK_GENERIC_REGION_2D
// #endif // (defined _DEBUG)
2) The following lines should be uncommented: #define __EXT_DEBUG_GRID_ASSERT_VALID( __PTR__ ) ;
#define __EXT_DEBUG_GRID_ASSERT_KINDOF( __CTYPE__, __PTR__ ) ;
#define __EXT_DEBUG_GRID_ASSERT( __SOME_EXPR__ ) ;
#define __EXT_DEBUG_GRID_VERIFY( __SOME_EXPR__ ) __SOME_EXPR__ ;
3) The following lines should be commented: // #define __EXT_DEBUG_GRID_ASSERT_VALID( __PTR__ ) ASSERT_VALID( __PTR__ ) ;
// #define __EXT_DEBUG_GRID_ASSERT_KINDOF( __CTYPE__, __PTR__ ) ASSERT_KINDOF( __CTYPE__, __PTR__ ) ;
// #define __EXT_DEBUG_GRID_ASSERT( __SOME_EXPR__ ) ASSERT( __SOME_EXPR__ ) ;
// #define __EXT_DEBUG_GRID_VERIFY( __SOME_EXPR__ ) VERIFY( __SOME_EXPR__ ) ;
|
|
|
Dominik Braendlin
|
Jul 20, 2010 - 2:35 AM
|
Dear Tech Support, I would like to specify a minimum width on a ribbon button which is using the __ECTN_DYNAMIC_POPUP flag. The purpose is to have three ribbon buttons underneath each other having the same width although the containing text may vary in width. Is this possible and if how do I do it. Could you please give an example? Thanks Adrian
|
|
|
Technical Support
|
Jul 20, 2010 - 4:50 AM
|
First of all, you should implement a CExtRibbonButton-derived class and override its CExtBarButton::RibbonILV_CalcSize() method. Your method should invoke the parent class method and then return a computed size with the width that is not less than the minimal width you need. Second, you should create and use your CExtRibbonNode-derived class which returns RUNTIME_CLASS of your ribbon button class from the overridden CExtRibbonNode::_OnRibbonGetButtonRTC() virtual method. You should use the ribbon node for all your buttons which should use the required minimal width restriction.
|
|
|
Robert Webb
|
Jul 15, 2010 - 8:55 PM
|
I just noticed that a feature has stopped working in our program. Presumably due to a change in ProfUIS. We have:
CExtPopupMenuWnd *menu;
VERIFY(menu->ItemInsert(FN_COPYBITMAP));
We do not have a CExtCmdItem associated with the ID for the item, nor do we need one. Previously this worked and we could handle the message ourselves when it arrived. Now we get an assertion in CExtPopupMenuWnd::ItemInsert() because there’s no CExtCmdItem.
We also add the item earlier to the system menu using good old ::AppendMenu(HMENU, ...). I don’t know whether that previously gave ProfUIS what it needed to recognise this command later. Any ideas? Thanks, Rob.
|
|
|
Technical Support
|
Jul 16, 2010 - 4:29 AM
|
By default, command items in a Prof-UIS popup menu are based on command descriptions stored in the command manager. The CExtPopupMenuWnd::ItemInsert() method inserts such menu commands. But a popup menu also supports menu commands which are not based on the command manager and not updated htrough MFC’s command updating mechanism. Such menu items are inserted through the CExtPopupMenuWnd::ItemInsertCommand() method or through the CExtPopupMenuWnd::LoadMenu() and CExtPopupMenuWnd::UpdateFromMenu() methods invoked with the bNoRefToCmdMngr flag parameter set to true.
|
|
|
Robert Webb
|
Jul 15, 2010 - 9:48 PM
|
I’ve found a fix for this by using:
VERIFY(menu->ItemInsert(FN_COPYBITMAP, -1, NULL, NULL, frame->m_hWnd)); Not sure what changed to require this, but no matter, now it works. Thanks, Rob.
|
|
|
Robert Webb
|
Jul 15, 2010 - 8:39 PM
|
Although it works fine on most machines, on some of our clients’ machines we have a property sheet that takes about a minute to draw! When the dialog is opened, the first page of the property sheet appears and appears very fast. However when switching to any of the other tabs, the new page loads incredibly slowly. We can see every individual control appearing one at a time, with maybe a second between each one. Every label, every edit box, one by one. On most machines the whole page comes up instantly, but on others it does this slow appearance making it more or less unusable. Our dialog is being created by a DLL the links to our main app, and we actually get the same problem whether we use MFC or ProfUIS controls and property pages/sheets, but we didn’t have the problem before using ProfUIS, and I still suspect it is related to ProfUIS. My guess is that the controls on the first page are created before the window is realised, which is fast, but the window is already visible by the time the second page is created, and maybe extra windowing messages are causing excessive repaints as each item is added, or something like that. The controls are added from a resource by the way, not directly from our code. Have you heard of anything like this before? Any thoughts on what could cause it or how to fix it? Thanks, Rob.
|
|
|
Technical Support
|
Jul 19, 2010 - 7:39 AM
|
The property page window becomes created when you activate it for the first time. They are created internally by the Windows Property Sheet control and then subclassed by MFC objects. So, you can fully lock the property page window updating via handling the WM_INITDIALOG message: ON_MESSAGE( WM_INITDIALOG, HandleInitDialog )
LRESULT CYourPropertyPage::HandleInitDialog( WPARAM, LPARAM )
{
::LockWindowUpdate( m_hWnd );
LRESULT lResult = CExtResizablePropertyPage::HandleInitDialog( 0, 0 );
::LockWindowUpdate( NULL );
return lResult;
}
If the slow effect occurs on first displaying of the property page window, then you can try to do the same with the WM_SHOWWINDOW message: ON_WM_SHOWWINDOW()
void CYourPropertyPage:: OnShowWindow( BOOL bShow, UINT nStatus )
{
::LockWindowUpdate( m_hWnd );
CExtResizablePropertyPage::OnShowWindow( bShow, nStatus );
::LockWindowUpdate( NULL );
}
|
|
|
Technical Support
|
Jul 16, 2010 - 4:31 AM
|
We think you should try the following:
1) Run the property sheet based app on a slow machine. Let it display its first tab page.
2) Run the SPY ++ tool on the same machine, spy all the messages of all the windows of all the threads in your app.
3) Select some slow tab page in your app. Take a look at the messages displayed in the SPY++ tool.
You can repeat the same test on fast machine. If the message loop is overloaded on a slow machine, then there is some hook based software is installed on it or some other reason is present. If the message loop is equally overloaded on both machines, then there must be something else like heavy idle time processing, a slow network problem, a slow printer detection, anything else related to specific settings and environment of a slow machine and set of APIs used in your APP.
|
|
|
Robert Webb
|
Jul 18, 2010 - 8:32 PM
|
Unfortunately we don’t have a machine that can reproduce it, and our client is in another country. They have two very different machines where this happens though (one new with up-to-date specs, and one 5 years old). I was thinking of using LockWindowUpdate() and UnlockWindowUpdate() around the code which populates the slow pages. I wonder if the first page, which is fast, is populated before the window is made visible, whereas the other pages might be populated while visible, and this may somehow slow it down. However, I don’t know where to lock the updates. The pages are populated via a dialog resource template, not in our code. It seems by OnInitDialog() the page is already populated. I tried overriding all versions of the virtual Create() and CreateIndirect() methods for the page, but neither are ever called. Do you have any clues as to where I could put my lock calls? Thanks, Rob.
|
|
|
Rado Manzela
|
Jul 15, 2010 - 6:25 AM
|
I need to display and edit long text in grid cell. Text does not contain \r\n, but I need to wrap it to keep cell width and expand/shrink grid’s row as necessary. I’ve tried to apply this style: ModifyStyleEx( __EGCS_EX_AUTO_SIZE_INPLACE_CONTROL| __EGCS_EX_WRAP_TEXT ,0); But while typing the edit control expands beyond current cell’s width up to width of whole grid. But there is important column next to edited cell which must not be covered by edit box while typing (it shows length of the text, I’ll need to update it while typing). I need the text to be visible all the time without any scrolling, so current row height must be changed dynamically while typing. Is it possible to achieve this?
|
|
|
Technical Support
|
Jul 19, 2010 - 7:40 AM
|
The CExtGridWnd::BestFitRow() method measures all the grid cells using the CExtGridCell::OnMeasureBestFitExtent() virtual method which is based on the CExtGridCell::MeasureCell() virtual method. The last method handles the grid cells with wrapped texts correctly:
if( pWndGrid != NULL && (dwCellStyleEx&(__EGCS_EX_WRAP_TEXT|__EGCS_EX_MULTILINE_TEXT)) != 0L )
{
if( ( dwCellStyleEx & __EGCS_EX_WRAP_TEXT ) != 0L )
nDrawTextFlags |= DT_WORDBREAK;
INT nWidth = pWndGrid->OnSiwQueryItemExtentH( nColNo );
INT nHeight = 0; //pWndGrid->OnSiwQueryItemExtentV( nRowNo );
rcCellTextMeasured = CRect(0,0,nWidth,nHeight);
}
else
nDrawTextFlags |= DT_SINGLELINE;
This can be verified in the ProfUIS_Controls sample application using the grid cell in the second row of the Text grid column of the Grid dialog page. This grid cell is initialized with the __EGCS_EX_WRAP_TEXT extended grid cell style in the CPageGrid::_InitColumnText() method: pCellString1->ModifyStyleEx( __EGCS_EX_WRAP_TEXT );
Double clicking the left header cell separators in this grid control makes the rows automatically resized via the CExtGridWnd::BestFitRow() method:  The grid cells with wrapped texts is the supported feature. The row height is adjusted correctly. All the words became displayed. The method you implemented also works on the Grid dialog page in the ProfUIS_Controls sample application. We tried to add the following into the CPageGrid::CMyGridWnd class: virtual void OnGbwResizingStateApply( bool bHorz, LONG nItemNo, INT nItemExtent )
{
CExtPPVW < CExtGridWnd > :: OnGbwResizingStateApply( bHorz, nItemNo, nItemExtent );
if( bHorz )
{
for( int row = 0; row < RowCountGet(); ++row )
BestFitRow( row );
}
}
This works and resizes grid cells with wrapped text correctly. So, we came to the following conclusion: there must be something specific in your project what makes the CExtGridWnd::BestFitRow() method incorrectly or there must be some issue in Prof-UIS but it depends on specific initialization of the grid control in your project. We had to ask you to provide us with more details.
|
|
|
Rado Manzela
|
Jul 19, 2010 - 9:12 AM
|
I’ve tried to modify your sample, but it does not work too good for me. Please try to initialize cell this way: pCellString1->TextSet( _T("aaa bbb ccc aaa bbb ccc aaa bbb ccc aaa bbb ccc aaa bbb ccc aaa bbb ccc ") ); and resize column slowly. In some width range where you can see "aaa bbb ccc aaa" in first line, cell shows only 4 lines + 1 pixel of 5th line where you can see only top pixel of the ’bbb’ letters. It works like this in unicode static release, windows XP. Maybe the same thing is causing problems in my application.
When I try unicode debug, even with original sample sometimes it makes corrupted stack message box while scrolling the grid. It is impossible to debug modified sample because of taht message when I start resizing the column.
|
|
|
Rado Manzela
|
Jul 19, 2010 - 9:13 AM
|
PS I’ve disabled center style //pCellString1->ModifyStyle( __EGCS_TA_HORZ_CENTER );
|
|
|
Technical Support
|
Jul 19, 2010 - 12:15 PM
|
Thank you very much for the detailed information. We found two issues related to the wrapped text in the CExtGridCell::MeasureCell() method: the grid lines and text area margins were not used in the measuring algorithm. Please update the source code for the following overloaded version of the CExtGridCell::MeasureCell() method:
CSize CExtGridCell::MeasureCell(
CExtGridWnd * pWndGrid, // can be NULL
CDC & dcMeasure,
LONG nVisibleColNo,
LONG nVisibleRowNo,
LONG nColNo,
LONG nRowNo,
INT nColType,
INT nRowType,
DWORD dwHelperPaintFlags
) const
{
__EXT_DEBUG_GRID_ASSERT_VALID( this );
__EXT_DEBUG_GRID_ASSERT( dcMeasure.GetSafeHdc() != NULL );
if( pWndGrid->GetSafeHwnd() == NULL )
pWndGrid = NULL;
DWORD dwCellStyle = GetStyle();
DWORD dwCellStyleEx = GetStyleEx();
// MEASURE ICON SIZE
CSize _sizeIcon = IconGetSize();
if( _sizeIcon.cx > 0 )
_sizeIcon.cx += 2;
// MEASURE EXISTING TEXT SIZE
UINT nDrawTextFlags = DT_LEFT|DT_TOP|DT_CALCRECT;
CRect rcCellTextMeasured( 0, 0, 0, 0 );
if( pWndGrid != NULL && (dwCellStyleEx&(__EGCS_EX_WRAP_TEXT|__EGCS_EX_MULTILINE_TEXT)) != 0L )
{
if( ( dwCellStyleEx & __EGCS_EX_WRAP_TEXT ) != 0L )
nDrawTextFlags |= DT_WORDBREAK;
INT nWidth = pWndGrid->OnSiwQueryItemExtentH( nColNo );
if( pWndGrid->GridLinesVertGet() )
nWidth --;
DWORD dwAreaFlags = CExtGridHitTestInfo::CellTypesToAreaFlags( nColType, nRowType );
CRect rcTextAreaMargins = OnQueryTextAreaMargins( *pWndGrid, dcMeasure, nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType, dwAreaFlags, dwHelperPaintFlags );
nWidth -= rcTextAreaMargins.left + rcTextAreaMargins.right;
INT nHeight = 0; //pWndGrid->OnSiwQueryItemExtentV( nRowNo );
rcCellTextMeasured = CRect(0,0,nWidth,nHeight);
}
else
nDrawTextFlags |= DT_SINGLELINE;
LPCTSTR strTextBuffer = LPCTSTR( GetTextBuffer() );
int nTextBufferLen =
( strTextBuffer != NULL )
? int(_tcslen(strTextBuffer))
: int(0);
HGDIOBJ hOldFont = NULL;
HFONT hCellFont = NULL;
bool bFontMustBeDestroyed = false;
if( pWndGrid != NULL )
{
hCellFont = OnQueryCellFont( *pWndGrid, nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType, 0, bFontMustBeDestroyed, 0 );
if( hCellFont == NULL )
{
bFontMustBeDestroyed = false;
hCellFont = (HFONT)pWndGrid->OnSiwGetDefaultFont().GetSafeHandle();
}
if( hCellFont != NULL )
hOldFont = ::SelectObject( dcMeasure, (HGDIOBJ)hCellFont );
}
OnAdjustMeasureTextFlags( nDrawTextFlags, nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType, 0 );
bool bTextIsMeasured = false;
if( nTextBufferLen > 0 )
{
CExtRichContentLayout::stat_DrawText(
dcMeasure.m_hDC,
strTextBuffer, nTextBufferLen,
(RECT *)&rcCellTextMeasured,
nDrawTextFlags, 0
);
bTextIsMeasured = true;
} // if( nTextBufferLen > 0 )
else
{
CExtSafeString strCopy;
TextGet( strCopy );
if( ! strCopy.IsEmpty() )
{
CExtRichContentLayout::stat_DrawText(
dcMeasure.m_hDC,
LPCTSTR( strCopy ), strCopy.GetLength(),
(RECT *)&rcCellTextMeasured,
nDrawTextFlags, 0
);
bTextIsMeasured = true;
} // if( ! strCopy.IsEmpty() )
} // else from if( nTextBufferLen > 0 )
if( !bTextIsMeasured )
rcCellTextMeasured = CRect( 0, 0, 0, 0 );
CRect rcCellTextMeasured2( 0, 0, 0, 0 );
static CExtSafeString g_sTestText( _T("AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz0123456789;[]{}\\/=+-_*&ˆ%$#@!~") );
CExtRichContentLayout::stat_DrawText(
dcMeasure.m_hDC,
LPCTSTR( g_sTestText ), g_sTestText.GetLength(),
(RECT *)&rcCellTextMeasured2,
nDrawTextFlags, 0
);
if( pWndGrid != NULL && hCellFont != NULL )
::SelectObject( dcMeasure, hOldFont );
if( bFontMustBeDestroyed && hCellFont != NULL )
::DeleteObject( hCellFont );
INT nAlignHeight = rcCellTextMeasured2.Height();
CSize _sizeText = rcCellTextMeasured.Size();
_sizeText.cy = max( _sizeText.cy, nAlignHeight );
if( _sizeText.cx > 0 )
_sizeText.cx += 4;
if( _sizeText.cy > 0 )
_sizeText.cy += 4;
if( pWndGrid != NULL )
{
CRect rcTextAreaMargins = OnQueryTextAreaMargins( *pWndGrid, dcMeasure, nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType, 0, 0 );
_sizeText.cx += rcTextAreaMargins.left + rcTextAreaMargins.right;
_sizeText.cy += rcTextAreaMargins.top + rcTextAreaMargins.bottom;
}
else
{
if( _sizeIcon.cx > 0 )
_sizeText.cx += 4;
}
// MEASURE BUTTONS SIZE
CSize _sizeAllButtons( 0, 0 );
if( (dwCellStyle&(__EGCS_BUTTON_ELLIPSIS|__EGCS_BUTTON_DROPDOWN|__EGCS_BUTTON_UPDOWN)) != 0
&& ( pWndGrid == NULL
|| (pWndGrid->BseGetStyle()&__EGWS_BSE_BUTTONS_PERSISTENT) != 0
)
&& ( dwHelperPaintFlags & __EGCPF_SIMPLIFIED_RENDERING_TARGET ) == 0
)
{
CSize _sizeOneButton(
::GetSystemMetrics( SM_CXVSCROLL ),
::GetSystemMetrics( SM_CYHSCROLL )
);
if( (dwCellStyle&__EGCS_BUTTON_ELLIPSIS) != 0 )
{
_sizeAllButtons.cx += _sizeOneButton.cx;
_sizeAllButtons.cy = max( _sizeAllButtons.cy, _sizeOneButton.cx );
}
if( (dwCellStyle&__EGCS_BUTTON_DROPDOWN) != 0 )
{
_sizeAllButtons.cx += _sizeOneButton.cx;
_sizeAllButtons.cy = max( _sizeAllButtons.cy, _sizeOneButton.cx );
}
if( (dwCellStyle&__EGCS_BUTTON_UPDOWN) != 0 )
{
_sizeAllButtons.cx += _sizeOneButton.cx;
_sizeAllButtons.cy = max( _sizeAllButtons.cy, _sizeOneButton.cx );
}
}
// MEASURE CHECK/RADIO SIZE
CSize _sizeCheck( 0, 0 );
if( (dwCellStyle&__EGCS_CHK_MASK) != 0 )
{
if( pWndGrid != NULL )
_sizeCheck =
OnCalcCheckSize(
false, false, ( (dwCellStyle&__EGCS_READ_ONLY) == 0 ) ? true : false, *pWndGrid, dcMeasure,
nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType, 0, 0
);
else
{
_sizeCheck.cx = 13;
_sizeCheck.cy = 13;
}
}
// MEASURE SORT ARROW SIZE
CSize _sizeSortArrow( 0, 0 );
if( (dwCellStyle&__EGCS_SORT_ARROW) != 0 )
{
_sizeSortArrow.cx = __EXT_SORT_ARROW_GLYPH_EXTENT_HORZ;
_sizeSortArrow.cy = __EXT_SORT_ARROW_GLYPH_EXTENT_VERT;
}
// MEASURE FOCUS ARROW SIZE
CSize _sizeFocusArrow( 0, 0 );
if( (dwCellStyle&(__EGCS_HDR_FOCUS_ARROW_RESERVE_SPACE|__EGCS_HDR_FOCUS_ARROW_DISPLAY)) != 0 )
{
_sizeFocusArrow.cx = __EXT_FOCUS_ARROW_GLYPH_EXTENT_HORZ;
_sizeFocusArrow.cy = __EXT_FOCUS_ARROW_GLYPH_EXTENT_VERT;
}
// MEASURE ENTIRE SIZE
CSize _sizeMeasured = _sizeIcon;
_sizeMeasured.cx += _sizeText.cx;
_sizeMeasured.cx += _sizeAllButtons.cx;
_sizeMeasured.cx += _sizeCheck.cx;
_sizeMeasured.cx += _sizeSortArrow.cx;
_sizeMeasured.cx += _sizeFocusArrow.cx;
_sizeMeasured.cy = max( _sizeMeasured.cy, _sizeText.cy );
_sizeMeasured.cy = max( _sizeMeasured.cy, _sizeAllButtons.cy );
_sizeMeasured.cy = max( _sizeMeasured.cy, _sizeCheck.cy );
_sizeMeasured.cy = max( _sizeMeasured.cy, _sizeSortArrow.cy );
_sizeMeasured.cy = max( _sizeMeasured.cy, _sizeFocusArrow.cy );
return _sizeMeasured;
}
|
|
|
Rado Manzela
|
Jul 20, 2010 - 2:38 AM
|
Thank you. Next problem is that when cell contains for example 2 lines (resized by BestFitRow()) and width of the column is set as low as possible to keep 2 lines, when you start editing of the cell, only 1 line edit box is created. I guess there will be still some problem with margins. Can you check it please?
I also need the cell to be edited after single click (selections are disabled). I’ve tried to use grid.BseModifyStyle(__EGWS_BSE_EDIT_SINGLE_LCLICK,0); but it seems it is ignored, I still have to use double click
|
|
|
Technical Support
|
Jul 20, 2010 - 9:50 AM
|
Could you please provide us a screen shot of the grid cell with 2 lines of text and the width of the column is set as low as possible to keep 2 lines? We tried to reproduce this in the ProfUIS_Controls but the editor window always covering entire grid cell. The screen shot will allow us to know the font setting on your computer and exact column width in pixels.
The __EGWS_BSE_EDIT_SINGLE_LCLICK style does not work if the grid control does not use any selection model. Please override CExtGridWnd::OnGbwAnalyzeCellMouseClickEvent() virtual method, hit test the clicked location and start the cell editor. Here is the sample of hit testing and editing code:
CExtGridHitTestInfo htInfo( point );
HitTest( htInfo, false, true );
if( htInfo.IsHoverEmpty() || ( ! htInfo.IsValidRect() ) )
return . . . // clicked location is nowhere
INT nColType = htInfo.GetInnerOuterTypeOfColumn(), nRowType = htInfo.GetInnerOuterTypeOfRow();
if( nColType != 0 || nRowType != 0 )
return . . . // clicked location is outer header area
return
OnGbwBeginEdit(
htInfo.m_nVisibleColNo, htInfo.m_nVisibleRowNo, htInfo.m_nColNo, htInfo.m_nRowNo, nColType,
nRowType, htInfo.m_rcExtra, htInfo.m_rcItem, CRect(0,0,0,0), true, NULL, GetSafeHwnd()
);
|
|
|
Technical Support
|
Jul 15, 2010 - 12:35 PM
|
The __EGCS_EX_AUTO_SIZE_INPLACE_CONTROL extended grid cell style expands the editor window only horizontally and never vertically. You don’t need it. The __EGCS_EX_WRAP_TEXT extended grid cell style makes the long single line text wrapped into multiple lines both in the cells area inside grid control and in the in-place activated cell editor control. But it does not change the row height and in-place editor height while typing. Besides, the cell’s text is not changed until you finished typing. This means the row height cannot be re-measured. So, you should override the CExtGridCell::OnInplaceControlTextInputVerify or CExtGridWnd::OnGridCellInplaceControlTextInputVerify() virtual method, re-measure the editor’s text, move the editor window and change the row height. The row height can be changed automatically if you assign the typed text to grid cell and use the CExtGridWnd::BestFitRow() method.
|
|
|
Rado Manzela
|
Jul 19, 2010 - 2:48 AM
|
Ive tried this but it seems CExtGridWnd::BestFitRow() with __EGCS_EX_WRAP_TEXT is buggy. Just when I set some string to cell - for example "aaa bbb ccc", use this override:
void CDescGrid::OnGbwResizingStateApply( bool bHorz, LONG nItemNo, INT nItemExtent ) { __super::OnGbwResizingStateApply(bHorz,nItemNo,nItemExtent); for (int row=0; row<RowCountGet(); ++row) { BestFitRow(row); } }
when I resize the column width to be maybe 1 pixel narrower than required, it does not draw the last word and keeps it 1 line high. I think it should resize the row to 2 lines and draw last word to second line.
|
|
|
Ulrich Heinicke
|
Jul 14, 2010 - 2:28 PM
|
Hi, i want to enable / disable a ribbon node in a ribbon group depends of the result of an operation. How i can i do this? Do you have an example? Thanks Ulrich
|
|
|
Technical Support
|
Jul 15, 2010 - 6:40 AM
|
The ribbon bar is a very extended version of the toolbar. Ribbon nodes are used for creating toolbar buttons inside a ribbon bar. Each button has its command identifier. Enabling/disabling toolbar buttons both in toolbar and ribbon bar should be done through the MFC’s command updating mechanism based in the CCmdUI class. You should add a command updating method and bind it to the command identifier of a ribbon button/node. This works for any kind of ribbon elements, any push buttons, text/combo fields, galleries and check box buttons.
|
|
|
Offer Har
|
Jul 9, 2010 - 12:08 AM
|
Dear Support, We use the following method for loading toolbar buttons:
CExtBitmap bmp;
bmp.LoadBMP_File(file, true);
bmp.AlphaColor(crTransparent, 0, 0);
HICON hIcon = bmp.CreateHICON();
g_CmdManager->CmdSetIcon(
strProfileName,
pCmdItemMenu->m_nCmdID,
hIcon,
false
); We would like to use 32 png files, and have them alpha blend (with white as the backgroung color) - what do we need to do to make it work? Thanks, Ron.
|
|
|
Offer Har
|
Jul 9, 2010 - 1:50 AM
|
OK... figured it out:
CExtSkinBitmap bmp;
bmpMenu.LoadPNG_File(file, true);
hIcon = bmp.CreateHICON(); Works great - one question - why is the CExtSkinBitmap not part if Prof-UIS? It is a very useful class. Ron.
|
|
|
Technical Support
|
Jul 9, 2010 - 4:48 AM
|
The CExtSkinBitmap class is part of ProfSkin library. It’s a very small library and you can link your project with it.
|
|
|
Robert Webb
|
Jul 6, 2010 - 8:47 PM
|
Our dialog has a bitmap, which we change depending on options chosen (using CExtLabel::SetBitmap()). The bitmap has transparency. Before Prof-UIS the background behind the bitmap was erased first, so the new image would appear properly. Now it is not erased, so parts of the previous bitmap show through in the transparent parts of the new bitmap. I’m sure I saw a post or article about how to fix this already, but I can’t find it. Can you point me to it again or tell me the best way to fix this? Thanks, Rob.
|
|
|
Technical Support
|
Jul 16, 2010 - 12:10 PM
|
The CExtResizableDialog and CExtResizablePropertyPage classes are very recommended to use with the WS_CLIPSIBLINGS|WS_CLIPCHIDLREN standard window styles. The WS_CLIPSIBLINGS style makes the child dialog isolated from other windows in the same window container (CExtResizablePropertySheet, CExtTabPageContainerWnd, other). The WS_CLIPCHIDLREN style makes each dialog control isolated and not intersecting with other controls. Prof-UIS common controls classes always draw their themed backgrounds via paint manager. These backgrounds are always consistent with the parent dialog window background. The pixels of dialog surfaces are never used by its children controls. This means you should redraw the label window - not a rectangular part of its parent dialog window. The CExtLabel control supports the 32-BPP transparent CExtBitmap bitmaps on any Windows OS starting from Windows 95/NT 4.0. You can assign it using the CExtLabel::SetBitmapEx() method and specify painting mode using the CExtLabel::SetImageMode method.
|
|
|
Robert Webb
|
Jul 18, 2010 - 8:17 PM
|
I tried adding the WS_CLIPSIBLINGS|WS_CLIPCHIDLREN styles to my pages, but they made things worse. First, I’m not sure where to add them. The earliest time I could find was in OnInitDialog(). Once added, the window updating became worse. Not only did changing the bitmap of a label leave trash behind in the transparent parts, but now if I drag the dialog partly off-screen and back on again, the transparent parts in my label’s bitmap again end up full of trash (echoes of other parts). My work-around of invalidating the label’s rectangle works, albeit a bit slow on-screen for some reason. So I guess I’ll stick with that. Thanks, Rob.
|
|
|
Technical Support
|
Jul 19, 2010 - 7:38 AM
|
Please set both the Clip Siblings and Clip Children properties of the dialog template resource on. Then please check all the group boxes and static frame rectangle controls on your dialog template resource. The Z order of these controls should be greater the Z orders of all the controls inside them. The window invalidating just delays the window repainting. Please invoke the UpdateWindow() API to make the bitmap label control repainted immediately.
|
|
|
Technical Support
|
Jul 7, 2010 - 7:19 AM
|
|
|
|
|
Robert Webb
|
Jul 15, 2010 - 8:30 PM
|
Hi, We’re not trying to draw a bitmap in the background, nor do anything with the background. We just want to leave it as default for the current theme. What we want to do is change the bitmap being displayed in a CExtLabel control. Our bitmap has transparency, and in the transparent parts the underlying dialog’s background is not redrawn as it was before we used ProfUIS. I have solved this now by getting the rectangle of our control and invalidating that rectangle in the dialog window, forcing it to redraw its background. I just would have thought that the ProfUIS dialog should redraw its background properly by default, as it would in MFC. But for now, problem solved. Thanks, Rob.
|
|
|
Adrian Ineichen
|
Jul 6, 2010 - 12:48 AM
|
Hi I use an CExtGridCellComboBox in a CExtGridWnd. In the method OnGridCellInputComplete I get the item data of the _cell parameter (which is a pointer in my case) and work with the referenced object. Now during this processing, an error can occur. This error I show within a message box. The problem is: when the message box appears, the drop down list of the comboBox grid cell is still visible. It disappears when I click somewhere else on the screen. This is very annoying for I need two clicks to confirm the message box: The first lets disappear the drop down list and second will be accepted by the message box. We use v2.70 Thanks Christian Herger
|
|
|
Technical Support
|
Jul 6, 2010 - 6:57 AM
|
The popup list box is a popup menu with a list box common control inside. The CExtPopupMenuWnd::CancelMenuTracking() static method closes any currently opened popup menus. You should invoke it before displaying a message box.
|
|
|
Offer Har
|
Jul 5, 2010 - 2:38 PM
|
Hi, We need to get a notification when the user changes the width of a column in a grid - how do we do this? Thanks, Ron.
|
|
|
Technical Support
|
Jul 6, 2010 - 6:57 AM
|
The CExtGridBaseWnd::OnGbwResizingStateApply() virtual method is invoked when the row height or column width is changed via drag-n-dropping cell boders.
|
|
|
Francesco Toscano
|
Jul 5, 2010 - 12:23 PM
|
Probably it is a very stupid question, Is it possible to add a ribbon Bar to a Dialog based application? If yes, is available any example? Regards.
|
|
|
Technical Support
|
Jul 6, 2010 - 6:57 AM
|
The RibbonPage sample demonstrates how to create a CExtRibbonPage window inside the CExtResizableDialog window. The CExtRibbonPage control is a simplified CExtRibbonBar without file button, tabs and quick access toolbar. You can create the CExtRibbonBar inside dialog and initialize it exactly like it’s created inside frame window. The only differences is that the dialog should invoke the CWnd::RepositionBars( 0, 0xFFFF, 0 ) code near the end of the OnInitDialog() virtual method and in the dialog’s OnSize() handler method.
|
|
|
Robert Hofstetter
|
Jul 4, 2010 - 7:35 PM
|
I tried to use a large font in CExtReportGridWnd by overriding OnSiwGetDefaultFont() function. The grid fonts are increased but the row heights remain the same. so, the texts on the neighboring rows overlap each other and make them not readable. Is this a bug or I need to do something else, e.g. increase the row height accordingly? The grid’s header control has the same problem. The header text is larger than the header height. Thanks for any suggestions
|
|
|
Robert Hofstetter
|
Jul 5, 2010 - 6:10 PM
|
Thanks for the reply. I actually use the same large font for every rows in the whole grid, not particular rows. Is there a simpler way so that the row height can grow bigger automatically according to the font height.
|
|
|
Technical Support
|
Jul 6, 2010 - 6:59 AM
|
Any row in Prof-UIS grids can have a fixed or variable height (see the CExtGridBaseWnd::FixedSizeRowsSet() method, the __EGBS_FIXED_SIZE_ROWS style and the CExtGridBaseWnd::DefaultRowHeightSet() method). You can specify fixed size rows in report grid control and change heights of all the rows with invoking the CExtGridBaseWnd::FixedSizeRowsSet() and CExtGridBaseWnd::DefaultRowHeightSet() methods. But this is not recommended because the group rows look better with larger row height.
|
|
|
Technical Support
|
Jul 5, 2010 - 12:13 PM
|
The report grid control always assumes you can use different fonts in any grid cells. To increase data row height in your report grid control you should do the following: 1) Override the following virtual method in your CExtReportGridWnd class:
virtual bool OnTreeQueryPlainGridModeVeticalLayout() const
{
return true;
}
2) Add at least one outer header column on the left: wndReportGrid.OuterColumnCountLeftSet( 1L, false );
This is needed for keeping information about a custom row height in each report grid’s data row. 3) If you don’t need outer header columns, then you can make it width equal to zero: wndReportGrid.OuterColumnWidthSet( true, 0L, 14 );
4) Initialize header cells in the outer header column at left and specify required row height: CExtGridCell * pCellHdr;
pCellHdr = GridCellGetOuterAtLeft( 0L, nRowNo, RUNTIME_CLASS( CExtGridCellHeaderFilter ) );
ASSERT_VALID( pCellHdr );
pCellHdr->ExtentSet( 40 ); The code above sets the row height to 40 pixels. If you need to change the height of outer header row at top, then invoke the following code: wndReportGrid.OuterRowHeightSet( true, 0L, 40 );
|
|
|
Charles Bisbee
|
Jul 2, 2010 - 3:47 PM
|
I have a window based on CExtResizableDialog. I need to create it with it hidden. When I create it, it flashes until ShowWindow(SW_HIDE) is called. I have tried calling ShowWindow(SW_HIDE) in both PreInitDialog and InitDialog for the derived class. The call in PreInitDialog seems to be too early (the dialog is still displayed.) The call in InitDialog is better than a call after create finishes but still results in a flash. How do I stop the Flash Thanks
|
|
|
Charles Bisbee
|
Jul 8, 2010 - 4:23 PM
|
Call me dumb. The WS_VISIBLE was on. Thanks for your patience
|
|
|
Technical Support
|
Jul 3, 2010 - 5:33 AM
|
Modal dialogs in MFC are initially visible. So, the correct solution would be to create a non-modal dialog. You should set the Visible property of your dialog template resource to false to make your dialog initially hidden. You don’t have to invoke any code to hide it. Then you should create your dialog using its Create() method rather than its DoModal() method. That’s all. But if you need a modal dialog type, then you should emulate the modal message loop manually. Here is the sample source code for all the tasks:
// this is a probably pointer to your main frame or main dialog window (it must be popup window)
CWnd * pParentWindowOfYourDialog = . . .
CYourDialog dlg( . . . );
if( ! dlg.Create( CYourDialog::IDD, pParentWindowOfYourDialog ) )
return . . .
//
// That’s all. Invisible dialog was created successfully.
// Now we will run the modal message loop for it:
//
pParentWindowOfYourDialog->EnableWindow( FALSE );
while( dlg.GetSafeHwnd() != NULL )
CExtPopupMenuWnd::PassMsgLoop( true );
pParentWindowOfYourDialog->EnableWindow( TRUE );
The code above works like a modal dialog for your app users. But this dialog is not exactly the same as a modal dialog. If you need the modal result of this dialog ( IDOK, IDCANCEL, etc), you should save it in some property of your dialog manually.
|
|