Forum

Dear Support,

I’d like to refresh an older bug-report I posted middle of January this year in the subject mentioned above. You wrote back to me that you would fix it, but version 2.64 still has the bug. I’d like to find out an approximate date on the fix.

Thank you!
Chris

We can offer a beta solution in this regard. You can download the latest source code from our ftp site (Prof-UIS 2.64.1).

Hello,

many thanks for releasing version 2.64. It seems to contain many great new features and improvements.

However, the following bugs, that have been reported earlier, still persist in Version 2.64:

1.
Gradient control bar backgrounds are not always painted correctly. CExtPaintManagerOffice2003::PaintDockerBkgnd() stopps filling of the gradient at x-position 686 and continues painting a solid rectangle up to the right border of the background. Depending on the display settings the solid color may not match the rightmost gradient color, which causes the display of a vertical "edge" in the background.

This effect can be reproduced with the MDI_DynamicBars sample and the Office 2007 (Release 2) Silver theme. On displays with lower color depth (16 bit) the effect can be seen better, but it is also there on true color displays. A screenshot, that shows the effect, has been sent by email to the Prof-UIS support team.

2.
Start the MDI_DynamicBars sample and make Dynamic Bar 8, Dynamic Bar 9 and Dynamic Bar 10 floating. Then dock Bar 9 and then Bar 10 together with bar 8 side by side in a row within the same floating container. Bar 8 to the left, Bar 9 in the middle, Bar 10 to the right, visible side by side in a row (not tabbed !!) within the same floating container. Now hide the floating container together with all three bars by clicking the X in the container’s NC area. Now select the menu entry View->Dynamic Resizable Bars->Dynamic Bar 10. Dynamic Bar 10 should become visible now - but nothing happens instead.

3.
Start the MDI_DynamicBars sample and make Dynamic Bar 8, Dynamic Bar 9 and Dynamic Bar 10 floating. Then dock Bar 9 and then Bar 10 together with bar 8 side by side in a row within the same floating container. Bar 8 to the left, Bar 9 in the middle, Bar 10 to the right, visible side by side in a row (not tabbed !!) within the same floating container (let’s call this "Figure 1"). Now hide the floating container together with all three bars by clicking the X in the container’s NC area. Now select the menu entry View->Dynamic Resizable Bars->Dynamic Bar 8. Dynamic Bar 8 appears as expected. Now select View->Dynamic Resizable Bars->Dynamic Bar 9. Dynamic Bar 9 appears as expected right of Dynamic Bar 8. Now select View->Dynamic Resizable Bars->Dynamic Bar 10. Dynamic Bar 10 appears, too, but the sizes of the bars, i.e. the ratio of their particular widths, does not match the original ratio of "Figure 1". In our case Bar 9 ends as a very narrow window with a width of a few pixels. In other words: the three bars are not restored with their previous width.

Regarding items 2 and 3 in your message, please update the source code for the CExtControlBar::DelayShow() method in ../Prof-UIS/Src/ExtControlBar.cpp file:

void CExtControlBar::DelayShow( BOOL bShow )
{
      ASSERT_VALID( this );
CMiniDockFrameWnd * pMiniFrame =
            DYNAMIC_DOWNCAST( CMiniDockFrameWnd, GetParentFrame() );
      if(         IsFloating()
            &&    (! IsVisible() )
            &&    (! IsFixedMode() )
            )
      {
            if( pMiniFrame != NULL )
            {
                  ASSERT_VALID( pMiniFrame );
                  pMiniFrame->ModifyStyle( 0, FWS_SNAPTOBARS );
            }
      }
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
      else
      if( m_bAutoHideMode )
            bShow = FALSE;
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
      if( pMiniFrame != NULL && bShow && m_pDockBar->GetSafeHwnd() != NULL )
      {
            CControlBar::DelayShow( bShow );
            CControlBar * pParentBar = DYNAMIC_DOWNCAST( CControlBar, m_pDockBar->GetParent() );
            if( pParentBar != NULL )
                  pParentBar->DelayShow( bShow );
            else
            {
                  pMiniFrame->RecalcLayout();
                  pMiniFrame->ShowWindow( SW_SHOWNA );
            }
            return;
      }
      CControlBar::DelayShow( bShow );
}

I can commit, that item 2 seems to be is solved now. Many thanks for taking care.

Item 3, however, still persists. The source update does NOT fix the problem!

Thank you for the kind words and reporting the problems.

1) As we mentioned earlier, in regard with this issue, we implemented a design similar to that available in Microsoft. To eliminate the transition effect, we changed the code a bit.

2,3) We reproduced the problem. It is the highest possible priority for us. We hope to fix this issue in a few days. We will notify as it is ready.

Dear Support,

I am using in my application the CExtPaintManagerOffice2007_R3_Obsidian as my installed paint manager.
I need to make minor modifications to it (change the default font color, use s different shade of gray as the dialogs background color)
What is the simplest way to achieve these goals?
Is there any tutorial on how to do it?

Thanks,
Ron.

The most Prof-UIS classes use the g_PaintManager->m_FontNormal font stored in the global paint manager. This allows you to easily change the entire GUI font (see the FunnyBars sample for details).

You can see how all the color constants are initialized in the CExtPaintManager::InitTranslatedColors() method and it is overridden in other paint managers . You can change any of them according to your requirements. As for the background gradient colors, simply override InitTranslatedColors() and modify the _2003CLR_GRADIENT_DARK and _2003CLR_GRADIENT_LIGHT constants.

You can set a custom paint manager in this way:

g_PaintManager.InstallPaintManager( new CYourPaintManager );

Are there any guidelines for deriving my own paint manager?
Can I derive my custom paint from any existing paint class?
Is there minimal function set i must implement?

Thanks,
Ron.

We implemented these paint manager classes as an internal and ready-to-use part of the framework. Actually to create a new paint manager, you would have to override most of the virtual methods. So the easiest way to create a new theme is to override InitTranslatedColors() method of an existing paint manager and set new custom colors.

Dear Support,

Is there any documentation of all the various values of the enums e_2003_colors_t, e_xp_colors_t and e_translated_colors_t?

There are so me values...

Thanks,
Ron.

The color constants are internal parts of different Prof-UIS paint managers which also have the status of internal parts of the library.

SO, if i derive a class from CExtPaintManagerOffice2007_R3_Obsidian, implement the virtual InitTranslatedColors, call the base class implementation and then do some color changes it should be fine?

Thanks,
Ron.

First of all the Office 2007 theme is colorizable only partially because it is partially based on bitmaps. We recommend to use the Office 2003 theme if you want to colorize everything like you can see in the ThemeColorizer sample application. The Office 2007 themes in fact is a colorized version of the Office 2003 theme plus a set of bitmap based painting algorithms for such UI items as push/check/radio buttons, combo boxes and non client window areas. The colorization is based on two colors: accent color and background color. All the other colors are computed from these two base colors in the InitTranslatedColors() method. If you choose the colorization based on the InitTranslatedColors() method, then we recommend you copy its body from the base class and compute all the colors like you wish. A simpler way is based on the meant above two colors only and the CColorizedThemeOffice2003 class from the ThemeColorizer sample application is a ready to use solution where custom accent/background colors are provided by the OnQueryThemeColors() virtual method.

How to modify only the statusbar color ?

How to modify only the background color of the statusbar and the mainframe menu ?

Dear Support,

I have a button I attached a menu to.
I would like the menu to have the exact same width as the button has, so it will look as an integral part of the button when the menu is opened.
How can this be done?

Thanks,
Ron.

There is no direct way to do this. But there is a workaround. First, create a CExtPopupMenuWnd-derived class and overridde the _CalcTrackSize method in it: call the mehod of the base class and then change the width in the returned CSize value as you want. Then create a CExtButton-derived class and override the _OnTrackPopup method. Leave the default method’s code but this line:

CExtPopupMenuWnd * pPopup = new CExtPopupMenuWnd;

Dear Support,

Currently for creating a button with menu, all I do is:

    CMenu menu;
    menu.LoadMenu(IDR_MENU);
    m_btn.m_menu.Attach(menu.Detach());

Should I leave these 3 lines as-is?

Thanks,
Ron.

Yes, you don’t need to change these lines.

It works fine...
There is one problem - when in item is highlighted in the menu, the highlight does not go the whole way.
It seems that there is another place in the menu that tells the menu to highlight the item only up to the original width, and not the width that i specified in _CalcTrackSize.
How to solve this problem?
Thanks,
Ron.

Please place a call of CExtPopupMenuWnd::_SyncItems() before returning the execution control from the overridden _CalcTrackSize() method.

Does not work. Stil the highlight item does not go all the way.
This is the code:

virtual CSize _CalcTrackSize()
{
    CSize sz = CExtPopupMenuWnd::_CalcTrackSize();
    CRect rc;
    m_pParentButton->GetWindowRect(rc);
    sz.cx = rc.Width();
    CExtPopupMenuWnd::_SyncItems();
    return sz;
}

Here is a newer version of the popup menu class with the custom menu width adjustment:

class CMyPopup : public CExtPopupMenuWnd
{
      virtual CSize _CalcTrackSize()
      {
            CSize _sizeDefault = CExtPopupMenuWnd::_CalcTrackSize();
            CRect rc;
            m_pParentButton->GetWindowRect( &rc );
            CSize _sizeNew = _sizeDefault;
            _sizeNew.cx = rc.Width();
            m_sizeFullItems.cx += _sizeNew.cx - _sizeDefault.cx; 
            return _sizeNew;
      }
};

//          ASSERT(
//                      m_sizeFullItems.cx >= m_sizeFullItems2.cx
//                &&    m_sizeFullItems.cy >= m_sizeFullItems2.cy
//                );

Thanks.
I didn’t comment the lines and it still works.
Are you sure i need to comment these lines out?

We are getting a following error. did any one know why is this coming?

Automatically linking with Prof-UIS library: ProfUIS262u.lib
(Professional User Interface Suite)
Prof-UIS native unicode character type support:
disabled (symbol __EXT_MFC_ENABLE_TEMPLATED_CHARS is not defined)
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(35) : error C2011: ’IDataSourceListener’ : ’struct’ type redefinition
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(35) : see declaration of ’IDataSourceListener’
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(43) : error C2011: ’IDataSource’ : ’struct’ type redefinition
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(43) : see declaration of ’IDataSource’
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(59) : error C2011: ’CDataSourceControl’ : ’class’ type redefinition
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(59) : see declaration of ’CDataSourceControl’
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(111) : error C2011: ’CDataBoundProperty’ : ’class’ type redefinition
c:\Program_Files\Microsoft_Visual_Studio_.NET_2003\Vc7\atlmfc\src\mfc\occimpl.h(111) : see declaration of ’CDataBoundProperty’
f:\seelan\Prof-UIS\Include\ExtColorDlg.h(86) : fatal error C1903: unable to recover from previous error(s); stopping compilation

here is my StdAfx.h


// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//

#if !defined(AFX_STDAFX_H__117DAA7D_792C_11D2_A69F_0008C7B2F515__INCLUDED_)
#define AFX_STDAFX_H__117DAA7D_792C_11D2_A69F_0008C7B2F515__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

#define VC_EXTRALEAN        // Exclude rarely-used stuff from Windows headers

#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions

//RIBBONBAR SN - ONLY BELOW LINE
#ifdef PROF_UIS
    #include <prof-uis.h>
    #include <../ProfSkin/ProfSkin.h>
#endif

#include <afxole.h> // MFC OLE classes
#include <afxodlgs.h> // MFC OLE dialog classes
#include <afxdisp.h> // MFC Automation classes
#include <afxctl.h>            // MFC OLE Control Support
#include <afxdocob.h>

#ifndef _AFX_NO_DB_SUPPORT
#include <afxdb.h>            // MFC ODBC database classes
#endif // _AFX_NO_DB_SUPPORT

#ifndef _AFX_NO_DAO_SUPPORT
#include <afxdao.h>            // MFC DAO database classes
#endif // _AFX_NO_DAO_SUPPORT

#include <afxdtctl.h>        // MFC support for Internet Explorer 4 Common Controls
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include <afxcmn.h>            // MFC support for Windows Common Controls
#endif // _AFX_NO_AFXCMN_SUPPORT

#include <afxsock.h>        // MFC socket extensions

#include "toolkit/secall.h"
#include "toolkit/ActvHost/constants.h"

#define _ATL_APARTMENT_THREADED
#include <atlbase.h>
//You may derive a class from CComModule and use it if you want to override
//something, but do not change the name of _Module
class CMAppModule : public CComModule
{
public:
    LONG Unlock();
    LONG Lock();
    DWORD dwThreadID;
};
extern CMAppModule _Module;
#include <atlcom.h>
#include <comdef.h>


#ifdef RB_INITGUID
    #include <initguid.h>        // Have to be included, for DEFINE_GUID mechanism to work
#endif


// Setting/resetting of resource handle
#ifdef MODULE_INSTANCE
    #undef MODULE_INSTANCE
#endif
#define MODULE_INSTANCE AfxGetInstanceHandle( ) // Instance handle of the application
#include "CommonMacros.h"

//{{AFX_INSERT_LOCATION}}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.
#define TBD(name) AfxMessageBox (_T(#name))

#endif // !defined(AFX_STDAFX_H__117DAA7D_792C_11D2_A69F_0008C7B2F515__INCLUDED_)

It is of little help to have the content of StdAfx.h here. Haven’t you checked if a newer SDK and/or DDK is installed as we suggested?

Please also check if a newer SDK and/or DDK is installed on your computer. Please check the Include folder list in your Visual Studio settings. Make sure that the Platform SDK paths are at the bottom of the list and default Visual C++ folders are above them. If this does not help, let us take a look at the content of your StdAfx.h file.

Regarding OnRibbonGalleryItemHoverChange
Whenever i move the mouse from one item to another placed in ribbongallery control it show the tooltip to me however for this we need mouse movement.

Because of this when i take mouse on any item very first time it does not show any tooltip and for that i need to move the mouse and bring back to same item.
Is there any other similar function which will do the same thing but not require mouse move change

1)    I have implemented ribbon gallery control inside ribbon bar same as shown in ribbon bar example Home-> Style Tab. which contains some buttons.
On clicking of each button i am doing certain functionality.

Need to know how will i get the functionality of OnUpdate so that I can enable/disable particular button in gallery
e. g a function is declared as below
void Class1::OnUpdateToolsVerifyBeamOrientation(CCmdUI* pCmdUI)

If i am using the button without gallery control it calls onupdate of that particular button when i click on ribbon tab which contains that button
however if the same button is inside gallery control it is not calling onupdate.

Hello,

in our applications it is sometimes useful to temporarily fix the current size of a CExtControlBar object, which is currently floating in a CExtMiniDockFrameWnd, and to prevent the user from changing the size with the mouse. In such cases it would be useful to give the CExtControlBar object control over the return value of CExtMiniDockFrameWnd::OnNcHitTest().

A suggested way to solve this, are the following extensions of the source code:

UINT CExtMiniDockFrameWnd::OnNcHitTest(CPoint point)
{
...
CExtControlBar * pExtBar = GetControlBarExt();
    if( pExtBar != NULL )
    {
        ASSERT_VALID( pExtBar );

        if(pExtBar->CalcNcHit(nHit, this, point)))
        {
            return nHit;
        }
...
}

and

class __PROF_UIS_API CExtControlBar
: public ...
{
...
    virtual bool CalcNcHit(UINT& nHit, CFrameWnd* pFrame, CPoint point) const { pFrame; point; return false; }
...
};

This would offer classes derived from CExtControlBar the chance to hook UINT CExtMiniDockFrameWnd::OnNcHitTest().


Is there any change, that a feature like is will be added to Prof-UIS?

If you need to lock all the bars, then it is handy to use the following code:

      CExtControlBar::g_bLockAllBars = true;
      pMainFrame->RecalcLayout();
      CExtControlBar::stat_RecalcBarMetrics( pMainFrame );

      CExtControlBar::_DraggingIsEnabled()
      CExtControlBar::_RowResizingIsEnabled()
      CExtControlBar::_RowRecalcingIsEnabled()
      CExtControlBar::_FloatStateChangingIsEnabled()
      CExtControlBar::_NcMenuButtonIsEnabled()
      CExtControlBar::_ClosingIsEnabled()
      CExtControlBar::_AutoHidingIsEnabled()
      CExtControlBar::OnConstructDockSiteControlBarPopupMenu()
      CExtControlBar::_CanDockToTabbedContainers()
      CExtControlBar::_CanDockLTRB()

I derive a new type from CExtReportGridColumn as follows:

class DxReportGridColumn : public CExtReportGridColumn {
DECLARE_DYNCREATE( DxReportGridColumn);

CRuntimeClass* pCellClass;
public:
DxReportGridColumn(CExtGridDataProvider *pDP = 0) : CExtReportGridColumn(pDP) { pCellClass = 0; }
void SetDefaultCellColumnClass( CRuntimeClass *pClass ) { pCellClass = pClass; }
CRuntimeClass* GetDefaultCellColumnClass( void ) { return pCellClass; }
};

In the ReportGrid I call:

DxReportGridColumn * pRGC = NULL;

pRGC = (DxReportGridColumn *) ReportColumnRegister( "ColumnName", "CategoryName", true,
false, RUNTIME_CLASS(DxReportGridColumn) );

The type of pRGC returned is always CExtReportGridColumn!! The constructor for my type is called so it is actually created however the type is downcast back to CExtReportGridColumn somewhere before it is returned by ReportColumnRegister. I can see this when I step into ReportColumnRegister code.

Dave

CExtReportGridColumn is derived from CExtGridCellHeader, which is derived from CExtGridCell, so when deriving a new class from CExtReportGridColumn, you need to do all steps required for the deriving of a new cell class. You need to use

DECLARE_SERIAL( DxReportGridColumn ); 
IMPLEMENT_ExtGridCell_Clone( DxReportGridColumn, CExtReportGridColumn);

IMPLEMENT_SERIAL( DxReportGridColumn, CExtReportGridColumn, VERSIONABLE_SCHEMA|1 ); // add this one line
 
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

It seems that column reordering using drag&drop causes that also column indexes used in ItemGetCell() are changed.
Call to ItemGetCell(x,1,....) gives another cell after column drag&drop to another place.
Is this by design or bug ?
I think column d&d should be transparent for ItemGetCell so I wouldn’t need to bother by column rearrangements made by user.
Thank you

So do I need to track column swapping in CExtTreeGridWnd and make my own coluns mapping?
I’d suggest you to implement this in future as part of all grid controls.
Thank you

You can use cell object pointers from the top outer row as unique column identifiers. In this case, we (or you) just need to implement only the one CellPointerToColumnIndex() method. This method could use a cached map of cell pointers to their column indixes and the cache could be updated automatically in the overridden CExtGridWnd::OnDataProviderSwapDroppedSeries() virtual method. But in the grid window, there can be many outer rows/columns at the left/top/right/bottom sides and the row/column swapping event will occur in two cases: drag-and-dropping outer cells and sorting (which is supported both horizontally and vertically). We think we should not implement the row/column-to-index mapping feature in the grid window to keep it working faster.

Hi,

I have some problems when I refresh my CCacheableGridBaseWnd derived class based on this sample. This happens when I call SiwFireCacheChanging with a vertical scrolling position different of 0 ; the data doesn’t correspond to its row and some appear twice.

Here’s my code :

BoardGrid.h :

class CBoardGrid : public CCacheableGridBaseWnd
{
   ...
}

void CBoardGrid::OnCacheHeaderCell(LONG nRealHeaderColNo,
		                        CExtGridDataProvider * pCacheDataStorage,
		                        LONG nCacheDataStorageColNo,
		                        LONG nCacheDataStorageRowNo)
{
    ...
}

void CBoardGrid::OnCacheDataCell(LONG nRealRangeColNo,
		                     LONG nRealRangeRowNo,
		                     CExtGridDataProvider * pCacheDataStorage,
		                     LONG nCacheDataStorageColNo,
		                     LONG nCacheDataStorageRowNo)
{

    ASSERT_VALID(this);
    ASSERT_VALID(pCacheDataStorage);

    if (nRealRangeRowNo >= m_pBoardsQueue->size() ||
        nRealRangeRowNo >= m_pSolutionsQueue->size())
    {
        pCacheDataStorage->CellRangeSet(nCacheDataStorageColNo, 
            nCacheDataStorageRowNo, 1, 1, NULL);
        return;
    }

    int nBrdNumber = (*m_pBoardsQueue)[nRealRangeRowNo].GetBoardNumber(); 
    CExtGridCellString cellData(pCacheDataStorage);

    cellData.ModifyStyle(__EGCS_READ_ONLY);
    cellData.BackColorSet(CExtGridCell::__ECS_ALL, 
        (nBrdNumber%2)?GRID_LINE_EVEN_COLOR:GRID_LINE_ODD_COLOR);
    cellData.TextColorSet(CExtGridCell::__ECS_ALL, 
        (!(nBrdNumber%2))?GRID_TEXT_EVEN_COLOR:GRID_TEXT_ODD_COLOR);

    CExtSafeString strDataCellText;
    strDataCellText.Format("%d", nBrdNumber);
    cellData.TextSet(LPCTSTR(strDataCellText));
    pCacheDataStorage->CellRangeSet(nCacheDataStorageColNo, 
        nCacheDataStorageRowNo, 1, 1, &cellData);
}

void CMainFrame::OnTimer(UINT_PTR nIDEvent)
{
    switch(nIDEvent)
    {
    
    ...

    case IDT_REFRESHING_RATE :
        {
            COptiMainDoc *pDoc = (COptiMainDoc*)GetDocBeforeDisplay();
            if (m_pCommGUI == NULL || pDoc == NULL || !m_bCommInitialized)
            {
                break;
            }
            pDoc->UpdateAllViews(NULL, HVU_BOARD);
        }
        break;

    default :
        break;
    }

    CVABMainFrame::OnTimer(nIDEvent);
}

void CBoardBaseView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint)
{
    if (!(lHint & HVU_BOARD) && lHint != HVU_ALL)
    {
        return;
    }

    m_gridBoardsQueue.SiwFireCacheChanging();

    CExtWA<CExtWS<CExtAFV<CFormView> > >::OnUpdate(pSender, lHint, pHint);
}

Hello,

we face a performance issue with floating, dockable CExtDynamicControlBars. When such bars are being dragged over areas, where they can be docked to other windows, they move a bit "sticky". This effect can be seen also on 3.0 GHz machines and it happens also with your MDI_DynamicBars sample.

The effect does not occur, if the CExtDynamicControlBars are changed from "dockable" to "floating". In this case the bars move smoothly and fast.

Thus there seems to be something in Prof-UIS related to dragging of dockable bars, that causes this effect.

Is there something we can do on our side to improve the performance of this feature?

How do I center the text displayed in a CExtHyperLinkButton? Also, is it possible to make the text multiline? I tried doing this in the VS2005 dialog editor, but the changes don’t appear when running the app.

I’d like to ask whether do you plan to implement replacement for MessageBox(). At least standard functionality with themed appearance.
It is very often used function IMHO and it looks weird when error/information messages in themed application have old design.

It would be also great if you would implement sorting by columns in CExtTreeGridWnd. It could sort siblings at the same level in tree hierarchy. Optionally recursively to last level or to given depth using some tree’s option variable (1=sort only children of root).
I guess I could do this by myself after some hard days of studying of dataprovider class, but maybe it could take couple of minutes to you
and would be useful for other users ;)

Thank you!

some example of usage could be this:

|name |amount|
-----------------------------
|order1 | $10 |
| \ item1 | $5 |
| \ item2 | $5 |
|order2 | $4 |
| \ item1 | $3 |
| \ item2 | $1 |

order’s amount is sum of all children items’ amount - provided by me.

user would be able to to sort tree by clicking to name column (this is how is the example sorted now) or amount column
( ascending order would be (order2,(item2,item1)),(order1(item1,item2))

Thank you for providing these details. We will add this feature in one of the next releases.

When I call CExtTreeGridWnd::ItemGetFirstChild() at item which contains no children, it asserts in
CExtTreeGridCellNode::TreeNodeGetChildAt( ULONG nPos ) at line
ASSERT( nPos < ULONG(m_arrChildren.GetSize()) );
Shouldn’t it return NULL instead?

ok. in the demo , function CChildView::OnUpdateTreeDeleteFocusedChildren()....
replace ItemGetChildCount() like this :

void CChildView::OnUpdateTreeDeleteFocusedChildren(CCmdUI* pCmdUI)
{
HTREEITEM htiFocus = ItemFocusGet();
if(        htiFocus == NULL
        ||    ItemGetFirstChild( htiFocus ) == NULL
//        ||    ItemGetChildCount( htiFocus ) == 0
        )


then focus last child and it will assert

We confirm this issue. To fix it, please update the source code for the CExtTreeGridCellNode::TreeNodeGetChildAt() method in ../Src/ExtTreeGridWnd.cpp:

CExtTreeGridCellNode * CExtTreeGridCellNode::TreeNodeGetChildAt( ULONG nPos )
{
      ASSERT_VALID( this );
      if( m_arrChildren.GetSize() == 0 )
            return NULL;
      ASSERT( nPos < ULONG(m_arrChildren.GetSize()) );
CExtTreeGridCellNode * pNode = m_arrChildren.GetAt( nPos );
      ASSERT_VALID( pNode );
      ASSERT( pNode->m_nOptIndex == nPos );
      return pNode;
}

I’ve tried the last 2.63.4 code and the bug is still there.

In this case we would like to ask you to help us reproduce the problem. Would you modify this test project to reproduce this assertion failure?

Hello,

it seems to me, that Prof-UIS uses the order in m_pDockSite->m_listControlBars and PtInRect() to determine a docking container, that fits to the current mouse position, when a control bar is about to be dragged.

Sometimes this causes a problem, when a bar is dragged over a visible bar, that covers another bar. Sometimes it happens, that the docking markers of the covered bar gain priority over the docking markers of the visible bar making it impossible to dock the dragged bar together with the visible bar.

It would be helpful, if the Z-order of the available bars would be evaluated, too, and if the bar with a "topmore" Z-position (i.e. that bar, that is currently "visible" at the mouse position) would receive priority over a covered bar.

We confirm the target bar hit testing is not always corresponding to Z-order of floating mini frame windows. But in all such cases the following is true: some of overlapped floating windows are placed into absolutely unusable state. So typically you don’t face the incorrect Z-order hit testing because you are keeping floating window so they are not intersected with each other.

Hello,

I just discovered a small display problem with the Office 2007 Silver Theme. This problem can be reproduced with the MDI_DynamicBars sample.

The gradient background visible in the upper menu/toolbar area of the main window ends after about two third of the main window width. Then it changes to a very light brownish background. This way the gradient background looks as if it were divided into two parts.

This problem does not occur with other themes.

Is this a software issue or a problem of our graphics system? Is anybody else able to reproduce this effect?

This behavior is by design. Actually the Office 2007 Silver theme is the same as Office 2003 under the Luna Silver theme. If you open Office 2003, you will see exactly the same gradient.

Ok, I am aware that Microsoft sometimes uses bitmaps of limited width and height (about 600 pixels) to paint gradient backgrounds in their software. Sometimes this causes nasty display effects, if the gradient area is bigger than the dimensions of the bitmap. We are aware of this.

As far as I understand your response it is a design goal of Prof-UIS to emulate even such Microsoft limitations.

Why do you believe it is a limitation of Microsoft Office? We would not agree with you on this. This gradient is not painted with a bitmap. The GradientFill() method works much faster than stretching a bitmap and we are pretty sure Microsoft uses this method (you can make sure of this by setting a low color depth for your desktop). We do not also see any reason not to draw the gradient up to the right most edge of the frame window: this would not affect the performance much. So this design is probably defined in a Microsoft’s specification and we follow this as well.

Would you send us some screenshots with nasty effects so we can offer you an appropriate solution?

Hello,

many thanks for your response.

>>
This gradient is not painted with a bitmap. The GradientFill() method works much faster than stretching a bitmap
<<
I fully agree with you here!! Microsoft sometimes seems to use stretched bitmaps instead of GradientFill() and I like it very much, that Prof-UIS is using GradientFill() instead of such bitmaps. No disagreement about this point!

>>
We do not also see any reason not to draw the gradient up to the right most edge of the frame window: this would not affect the performance much.
<<
But exactly this is the point! You actually do NOT draw the gradient up to the right most edge of the frame window! If you did as you say everything would be perfect. Actually the gradient stops at pixel 686 (search for ’686’ in CExtPaintManager.cpp, please, and you will see what I mean). This causes nasty affects on several of our computers. I will send you a screenshot, that shows this effect.

Thank you for the screenshot. The problem is that you are using the 16-bit color depth for the display. Please find the following lines in the CExtPaintManagerOffice2003::PaintDockerBkgnd method:

if( ! rcDst2.IsRectNull() )
    dc.FillSolidRect( &rcDst2, clrRight );

if( ! rcDst2.IsRectNull() )
{
    if( ::GetDeviceCaps( dc.m_hDC, BITSPIXEL ) > 16 )
        dc.FillSolidRect( &rcDst2, clrRight );
    else
        stat_PaintGradientRect(
            dc,
            rcDst2,
            clrRight,
            clrRight,
            false,
            64
            );
}

Hello,

ok, but why does Prof-UIS draw the complete background in two steps? What is the magic behind the "686" in the CExtPaintManagerOffice2003::PaintDockerBkgnd method?

Function call:

CExtRibbonPage::RedrawCommandItems( nCmdID );

does not do anything in the RibbonPage example because the toolbar mapping is empty. How to update command items when needed?

Sorry, do you mean that these functions were just added and are not a part of the latest downloadable code (ZIP)?

No, these methods were added to the CExtRibbonPage class immediately before answering your message. They are not inside the latest downloadable source code yet. We are sorry for inconvenience. But they will be statically available in future of course. So, please add them manually or we can provide you with the newer download.

I check it in the sample applicaiton under the debugger. The different function is actually called for CExtRibbonPage::RedrawCommandItems( nCmdID )

INT CExtCustomizeSite::RedrawCommandItems(
    UINT nCmdID,
    bool bUpdateWindows // = true
    ) const
{
    ASSERT( CExtCmdManager::IsCommand(nCmdID) );
INT nUpdateBtnsCount = 0;
    for(    POSITION pos = m_mapToolBars.GetStartPosition();
            pos != NULL;
            )
    {
        CExtToolControlBar * pBar = NULL;
        CToolBarCustomizeInfo * pInfo = NULL;
        m_mapToolBars.GetNextAssoc( pos, (void * &)pBar, (void * &)pInfo );
        ASSERT( pBar != NULL );
        ASSERT( pInfo != NULL );
        if( !pBar->IsVisible() )
            continue;
        INT nBtnsCount = pBar->GetButtonsCount();
        if( nBtnsCount == 0 )
            continue;
        bool bUpdateBar = false;
        for( INT nBtnIdx = 0; nBtnIdx < nBtnsCount; nBtnIdx++ )
        {
            CExtBarButton * pTBB = pBar->GetButton( nBtnIdx );
            ASSERT_VALID( pTBB );
            UINT nTbbCmdID = pTBB->GetCmdID( false );
            if(        nTbbCmdID != nCmdID
                ||    (! pTBB->IsVisible() )
                ||    (pTBB->GetStyle()&TBBS_HIDDEN) != 0
                )
                continue;
            nUpdateBtnsCount ++;
            bUpdateBar = true;
            if( pTBB->IsKindOf(RUNTIME_CLASS(CExtBarColorButton)) )
                ((CExtBarColorButton*)pTBB)->OnSyncIcon();
            pTBB->RedrawButton( false );
        } // for( INT nBtnIdx = 0; nBtnIdx < nBtnsCount; nBtnIdx++ )
        if( bUpdateWindows && bUpdateBar )
            pBar->UpdateWindow();
    }
    return nUpdateBtnsCount;
}

and the m_mapToolBars is empty, so it does not do anything. Note that under the debugger the RedrawCommandItems() method is called from the CExtCustomizeSite class not from the CExtRibbonPage. This is in the standard sample code, I did not make any changes.

Hello,

I need to make all CExtDynamicControlBar windows, that are contained in the same floating container, visible with one menu command, when this floating container is hidden.

Imagine a scenario, where three CExtDynamicControlBar windows are docked in the same floating container, are hidden by pressing the X of this container. It should now be possible, to make these windows visible again with one single menu command.

With the menu item associated with the control bar ID of one of these bars it is just possible to make one bar visible at a time. Thus the user would have to select three menu items, to make all bars contained in that floating container visible again (can be reproduced with your MDI_DynamicBars example).

I tried the following approach:

if (GetParentFrame()->IsKindOf(RUNTIME_CLASS(CMiniFrameWnd)) &&
(!GetParentFrame()->IsWindowVisible()))
{
    CFrameWnd* poMainFrame = (CFrameWnd*)AfxGetMainWnd();

    POSITION pos = poMainFrame->m_listControlBars.GetHeadPosition();
    while (pos != NULL)
    {
        CControlBar* poBar = (CControlBar*)poMainFrame->m_listControlBars.GetNext(pos);

        if ((poBar != NULL) &&
        (poBar != this) &&
        (poBar->IsKindOf(RUNTIME_CLASS(CExtDynamicControlBar))) &&
        (poBar->GetParentFrame() == GetParentFrame()))
        {
            CExtControlBar::DoFrameBarCheckCmd((CFrameWnd*)AfxGetMainWnd(), poBar->GetDlgCtrlID(),false);
        }
    }
}
CExtControlBar::DoFrameBarCheckCmd((CFrameWnd*)AfxGetMainWnd(), GetDlgCtrlID(),    false);

The above code shall make all "sibling" bars visible, too, when one of these bars is about to become visible.

This works well, when all bars are tabbed in the floating container. When all bars are docked, then all bars become visible. However, the new size, which is assigned to each of these bars is different from their former size, when the X was pressed to close the floating container. In other words: the bars are not restored with their previous size.

Any ideas how to avoid this effect?

As you know the feature you want to implement is not supported in the Visual Studio-style docking. There is no way in Visual Studio to make all control bars in a floating group visible at once. But the behavior you requested sounds reasonable and will certainly be handy for users. However to implement it as a general feature requires time and effort. At the moment, we can offer you another solution. There is a StateInFile sample in Prof-UIS, which allows the user to state the UI state into a file. So the solution could be to save the state of grouped control bars into a file ( or under some registry key) and then when the user clicks a menu item or button, this state is restored and the user can see all the control bars restored into their floating container.

Hello,

many thanks for considering this request as a general feature.
>>
At the moment, we can offer you another solution. There is a StateInFile sample in Prof-UIS, which allows the user to state the UI state into a file. So the solution could be to save the state of grouped control bars into a file ( or under some registry key) and then when the user clicks a menu item or button, this state is restored and the user can see all the control bars restored into their floating container.
<<
This sounds like a rather tricky workaround. Could you please tell me, how to serialize the state of just those control bars to a CArchive, that are grouped together in a floating container? I would prefer to use a CMemFile as a temporary storage for the state of the affected control bars.

The CExtControlBar::ProfileBarStateLoad() and CExtControlBar::ProfileBarStateSave() static methods are used in the most of Prof-UIS samples for loading /saving the control bar state from/to the system registry. The CExtControlBar::ProfileBarStateSerialize() static method also laods/saves the state but it uses the reference to the CArchive object as parameter. This archive can be based either on the CMemFile memory file object or on the CFile file object on disk.

Yes, I am aware of these methods. But as far as I understand, these methods will save and restore the state of ALL bars. This will very probably not solve my problem.

CExtControlBar::ProfileBarStateSerialize() will probably restore the status of ALL bars with regard to the moment, when the floating container with the grouped bars was hidden. While the floating container was hidden, some other "third party" bars may have changed their status. These status changes would be reset, too, when CExtControlBar::ProfileBarStateSerialize() is invoked, correct?

For this reason it is necessary, just to serialize only the state of the grouped bars, but nothing else. Is this possible and if so, how?

The CExtControlBar::ProfileBarStateLoad(), CExtControlBar::ProfileBarStateSave() and CExtControlBar::ProfileBarStateSerialize() methods allow you to load and save the state of the following control bars:

1) All the control bars.
2) Only the fixed-size toolbars (menu bar, toolbars, palette bars, status bar and other bars located in outer frame areas).
3) Only the resizable control bars.

Actually the feature of serializing the UI state of a separate group of control bars is not supported. As said earlier, we developed the CExtControlBar windows to be similar to the dockable panes in Visual Studio .NET and Visual Studio 2005. In fact there is no ready-to-use solution that would allow you to restore the positions of several control bars at once. We can only add this to our to-do list. But in any case, when we are ready to start working on this, we will have to carefully think over every detail.

Hello,

Understood. I appreciate very much, that you put it on your to do list. This will be a feature, which is very handy for many end users.

Hello,

>>
However, the new size, which is assigned to each of these bars is different from their former size, when the X was pressed to close the floating container. In other words: the bars are not restored with their previous size.
<<
It is possible to reproduce a similar problem with the MDI_DynamicBars sample:

1. Dock two dynamic bars together in the same floating frame.
2. Hide the left bar by clicking the X in the NC area of the left bar.
3. Make the left bar visible via the menu.

Both bars are restored with their previous size.

So far so good.

Now:

1. Dock two dynamic bars together in the same floating frame.
2. Hide the right bar by clicking the X in the NC area of the right bar.
3. Make the right bar visible via the menu.

This time the bars are not (!) restored with their previous size.

Even more: if the "hide and show" procedure for the right bar is repeated several times, then the right bar gets smaller and smaller each time. If this procedure is repeated with the left bar, then both bars maintain their size.

From my point of view this is a (small) bug and I guess, that the solution for this effect will probably also solve my original problem.

Hello,

playing further with the MDI_DynamicBars I found another problem, that can be easily reproduced:

1. Start the sample with a cleared registry.
2. Dock Dynamic Bar 1, Dynamic Bar 2 and Dynamic Bar 3 within the same floating container, 1 on the left, 2 in the middle, 3 on the right.
3. Press X in the NC area of the floating container to hide all three bars in one step.
4. Now select the menu item, that belongs to bar 3.

Nothing happens. I would expect, though, that the container becomes visible again with bar 3 as the only content. A bug?

We failed to reproduce this problem with the latest Prof-UIS source code you can download from our web site (i.e. 2.63.3 or 2.63.4).

Additionally, the state of the dynamic control bars should be managed using the CExtDynamicControlBar::BarStateGet() and CExtDynamicControlBar::BarStateSet() methods. If you want to make the bar visible without changing its state, you can do this by calling pDynamicBar->BarStateSet( pDynamicBar->BarStateGet(), true ).

If you need to show and activate (set focus to bar’s child window) only one control bar (simple or dynamic) in any state except for the document state of dynamic bar, then you should send the WM_COMMAND message to the main frame window and specify bar’s dialog control identifier as the command identifier: pMainFrame->SendMessage( WM_COMMAND, WPARAM( pBar->GetDlgCtrlID() ), LPARAM( 0 ) ).

It is not possible to display/activate more than one bar in the auto-hidden mode. This is a limitation of the auto-hiding feature by its design.

Hello,

>>
We failed to reproduce this problem with the latest Prof-UIS source code you can download from our web site (i.e. 2.63.3 or 2.63.4).
<<
the following bug still persists in Version 2.63.3:

1. Start the MDI_DynamicBars sample with a cleared registry.
2. Dock Dynamic Bar 1, Dynamic Bar 2 and Dynamic Bar 3 within the same floating container, 1 on the left, 2 in the middle, 3 on the right.
3. Press X in the NC area of the floating container to hide all three bars in one step.
4. Now select the menu item, that belongs to bar 3.

Nothing happens. I would expect, though, that the container becomes visible again with bar 3 as the only content.

We could not try with 2.63.4, because on the contrary to your statement we didn’t find this version on your web site.

Hello,

>>
It is not possible to display/activate more than one bar in the auto-hidden mode. This is a limitation of the auto-hiding feature by its design.
<<
I was not referring to bars in auto-hidden mode. I meant several bars, that are docked or tabbed in the same floating container.

Assume a scenario, in which a user has arranged - say - three docked bars side by side in a floating container. He is able to hide the complete container (including all three bars) with one single click to the X in the upper right corner of the container. But he is not able to make the container with all three bars visible again with one click. Instead he has to go to the menu three times and to click to each particular menu item, that belongs to each bar.

In our applications we make very extensive use of such bars. It is even possible, that users arrange 5 or even more bars this way. I don’t find it very convenient for the end user to force him to select 5 or even more menu items in order to make a window visible again in the same arrangement as before, that he closed before with one click to an X.

Hello,

>>
We failed to reproduce this problem with the latest Prof-UIS source code you can download from our web site (i.e. 2.63.3 or 2.63.4).
<<
We will verify this as soon as an official release (incl. installer) of this or a subsequent version is available.

Hello,

we want to create a CExtDynamicControlBar, that is initially hidden and floating.

When FloatControlBar() is being called after creating the bar with BarAlloc(), then the bar becomes temporarily visible. When FloatControlBar() is not called, then the bar is docked, when it is made visible later.

How can we create an initially hidden, floating bar?

It seems you mean the case when your application runs for the first time on the end user machine. Here is how you can easily achieve this:
1) Run your application and make all control bars docked and/or floating so that they have the desirable layout (the one the user should see when your application starts for the first time). Hide some control bars and containers if needed.

2) Exit your application. The layout and state of control bars are now saved either to the registry or to a file.

3) Distribute the .reg file or the file with saved ui state to target machines (inside your installer).

Many thanks for the reponse.

With "classic" MFC and CControlBar objects one just had to create the bar and call FloatControlBar without calling ShowControlBar.

As far as I understand your response this can be now easily achieved with Prof-UIS and CExtDynamicControlBar by replacing this single line of code by a procedure, that creates a .reg or file, which contains the desired status of the bar and by extending the installation procedure of the application to include this .reg or file and to install this file on the target computer of all end users. Many thanks for pointing me to this solution, which is really easy compared to classic MFC.

You should not create any special code in your project: simply run your app, then run regedit and export the folder with ui settng to a .reg file.