Forum

Thank You

// Arkin

I noted that OnGenerateColorBtnIcon() is no longer virtual in the latest 2.53 version. Is there a particular reason for that?

Dear Support,

My app has some DynamicControlBars and handles a timer with OnTimer(), as well. I get an Assertion, when during docking any of my DynamicControlBars, OnTimer tries to pop up a messagebox with AfxMessageBox(). In Call Stack I can see it comes from CMiniDockFrameWnd::WindowProc. It doesn’t happen every time, but I couldn’t find out yet in which state of the docking mechanism it happens and in which it doesn’t.

Thank you:
Chris

Is it possible to make the ID_EXT_DYN_BAR_AUTO_HIDE command toggle autohide on/off as in Visual Studio 2005 IDE?

May I simply modify the code (ExtControlBar.cpp - CExtDynamicControlBar::WindowProc) as:

...
            case ID_EXT_DYN_BAR_AUTO_HIDE:
                if (AutoHideModeGet()) {
                    BarStateSet( __EDBS_DOCKED, true );
                }
                else {
                    BarStateSet( __EDBS_AUTO_HIDDEN, true );
                }
            break;
...

or is there any potential problem doint that?

Thank you.

Hi,

I have a dialog created with CExtResizableDialog and a Color Picker with CExtColorButton. I want to handle its event in dialog...

How do i do that?

Thank you

Arkin

You can reproduce it in the MDI_DynamicBars sample (screenshot).

Steps to reproduce it:

1) click on the right control bar to activate it
2) right click on the non-active left control bar caption in a position close to the active bar caption, so that the popup menu will partially cover the active bar caption.

Dear Support,

In a command-handler of my app I remove all buttons of my toolbars and insert some again. After that of course I invalidate them again as described in your help:

if(m_wndToolBar.IsVisible() ){
m_wndToolBar.GetParentFrame()->RecalcLayout();
m_wndToolBar.Invalidate();
m_wndToolBar.UpdateWindow();
}

But after command-handler returns, no button can be seen in the toolbar, although I can make them visible again by making the toolbar floating (also visible after docking toolbar back again). The problem might be with removing _all_ buttons, because if I don’t remove all, but leave one behind, it all works again. Could you please check this issue?

Thank you: Chris

First of all: I didn’t mention I’m using v2.52 with VS7.1

Second: I investigated a little further. It seems like my problem can be solved like this: before the updating code-segment mentioned above, I have to set the bDoRecalcLayout parameter to TRUE in the last call of either InsertButton or RemoveButton. I never set this parameter to TRUE before, thinking that later on calling m_wndToolBar.GetParentFrame()->RecalcLayout(); does the same. Was this behaviour intentional?

Chris.

If you repaint a toolbar with the Invalidate() and UpdateWindow() methods, that means you simply delivers the WM_PAINT message to the toolbar. But it does not know whether the internal _RecalcPositionsImpl() method should be invoked for recalculating all the mutual button positions. So, you can use the current solution or invoke toolbar’s CWnd::SetWindowPos() method with the SWP_FRAMECHANGED flag.

I am calling both InsertButton and RemoveButton in a loop, so I’d rather not set bDoRecalcLayout parameter to TRUE in them, making CExtToolControlBar::_RecalcLayoutImpl(); to be called a lot of times. I tried your solution, calling CWnd::SetWindowPos() with SWP_FRAMECHANGED. Since I don’t want any other parameter of SetWindowPos to be used, I used SWP_FRAMECHANGED|SWP_NOMOVE|SWP_NOSIZE|SWP_NOZORDER as nFlags. But that didn’t work either, toolbar buttons were still invisible.
So I just made a public RecalcLayout method of my CExtToolControlBar-derived class, calling the protected CExtToolControlBar::_RecalcLayoutImpl(); method in it. So now calling this RecalcLayout after my loops works perfectly, with only a little flickering. Are there any dangers of this solution?

Thank you:
Chris

We do not see anything dangerous in this solution. You can send us your project so we can suggest an absolutely flicker free solution.

The mentioned flickering affects only the icons, and only those disabled at the moment of recalculating the layout. Those icons appear as enabled for a blink, but OnUpdate... handlers turn them disabled right after. I don’t think there’s an absolutely flicker free solution for that. I can live with this blink ;) But if you have any idea of how to eliminate it, I’ll try it of course.

Thank you for all your help:
Chris.

We think you need to use pToolBar->SetReraw( FALSE ) before you change buttons and pToolBar->SetReraw( TRUE ) after that.

I may have found a bug. Steps to reproduce it (MDI_DynamicBars sample):

1) Dock two bars as in this screenshot
2) Autohide one of them (screenshot 1, screenshot 2)
3) Resize the non-autohidden bar as in this screenshot
4) If you show the autohidden bar, you will see it has been resized as well (screenshot)

If instead of resizing the non-autohidden bar, you resize the autohidden one, nothing happens (screenshot), but as soon as the main frame layout is recalculated (e.g. if you resize the main frame o change the layout of any other bar), the non-autohidden bar is suddenly resized as the autohidden one (screenshot)

I am using the v2.53 downloaded yesterday from your ftp site.

Hello,

is there an easy way to programmatically set the width of a floating CExtToolControlBar, so that it automatically wraps and chooses an appropriate height to fit the new width? I was able to do that with normal mfc toolbars playing with the m_nMRUWidth member, but the same approach does not seem to work with CExtToolControlBar. It is not necessary that the toolbar accepts exactly the width set from the program, but it should be resized to be close to it. Please let me know your advices, thank you.

Here is the solution which you can test with the m_wndToolBarStandard toolbar in the DRAWCLI sample. Just put the following code at the end of the CMainFrame::OnCreate() method and play with the first parameter of the CalcDynamicLayout() method:

m_wndToolBarStandard.FloatControlBar(CPoint(400,400));
m_wndToolBarStandard.CalcDynamicLayout(
    200,
    LM_HORZ|LM_COMMIT
    );
m_wndToolBarStandard.GetParentFrame()->RecalcLayout();

Hello,

some time ago I submitted a but related to CExtMiniDockFrameWnd resize and you provided a fix. I have just noted that the problem is not fully solved.

To reproduce the behaviour:


1) at the end of CMainFrame::OnCreate(), add buttons to make the toolbar very large:

for (int k=0;k<10;k++)
m_wndToolBar2.InsertButton(-1,ID_VIEW_LIKE_STUDIO_2005);


2) move the floating toolbar to the left so that most of it is outside the left border of the screen


3) drag its right border to make it layout as a single row.


What happens (at least here on my PC) is that the window start looping between the full width and the width that CExtMiniDockFrameWnd::OnTimer(5) attempts to set. Would it be possible to force the floating control bar to wrap into two or more lines in those cases?

Dear Sir,

I want to use an external DLL for a third party of my interface.

How can I use your library by both my application and my external DLL with the theme the user defined ?

Thanks,

Simon

Would you please send me a sample for CExtGridWnd in a dialog?

Could you please send me this example too?
Thanks

We sent the project you requested via e-mail.

Could I get a copy of this sample??

It seems pretty popular! ;)

Thanks,

ed

Could you send me this sample as well?

Thanks in advance

We sent this project to you by e-mail.

Thanks for the sample.

I’m having a problem with selection on the grid. I created the control with the same style and exstyle as those in your sample, and created a subclass of CExtGridWnd. When I make a selection on the grid when it doesn’t have focus the selection is correctly shown, but once the grid has focus the selection is not changed in the display, even though it is saved cause when the grid lose focus the last selection is shown correctly again. Here’s the grid code:


class CMyGrid : public CExtGridWnd {
public:
    DECLARE_DYNCREATE(CMyGrid);

// Attributes
public:

// Implementation
public:
    void InitGrid();
};


IMPLEMENT_DYNCREATE(CMyGrid, CExtGridWnd);

void CMyGrid::InitGrid() {
    SiwModifyStyle(__EGBS_FIXED_SIZE_ROWS | __EGBS_SFB_FULL_ROWS |
            __EGBS_GRIDLINES | __EGBS_NO_HIDE_SELECTION, 0, false);

    OuterRowCountTopSet(2);

    ColumnAdd(5, false);
    for (int i = 0; i < 5; i++) {
        CExtGridCell* pCell = GridCellGetOuterAtTop(i, 0,
                RUNTIME_CLASS(CExtGridCellHeader));
        pCell->TextSet("X");
        pCell->ModifyStyle(__EGCS_TA_HORZ_CENTER);
        pCell->ExtentSet(80);
    }

    RowAdd(5, false);
    CExtGridCellVariant* pDataCell;
    for (int i = 0; i < RowCountGet(); i++) {
        for (int j = 1; j < ColumnCountGet(); j++) {
            pDataCell = STATIC_DOWNCAST(CExtGridCellVariant,
                    GridCellGet(j, i, 0, 0, RUNTIME_CLASS(CExtGridCellCurrency)));
            pDataCell->ModifyStyle(__EGCS_NO_INPLACE_CONTROL);
            pDataCell->_VariantAssign(0.0);
        }
    }

    OnSwUpdateScrollBars();
}


I call the InitGrid method in the OnInitDialog of the dialog.

You forgot to specify the scrolling strategy styles (__ESIS_STH_PIXEL|__ESIS_STV_ITEM styles) when invoking SiwModifyStyle(). Here is how to initialize the grid correctly:

void InitGrid()
{
    SiwModifyStyle(
        __ESIS_STH_PIXEL     // IMPORTANT: horizontal scrolling strategy
            |__ESIS_STV_ITEM // IMPORTANT: vertical scrolling strategy
            |__EGBS_FIXED_SIZE_ROWS
            |__EGBS_SFB_FULL_ROWS
            |__EGBS_GRIDLINES
            |__EGBS_NO_HIDE_SELECTION,
        0,
        false
        );
    OuterRowCountTopSet( 2 );
    ColumnAdd( 5, false );
    int  i, j;
    for( i = 0; i < 5; i++ )
    {
        CExtGridCell* pCell =
            GridCellGetOuterAtTop(
                i,
                0,
                RUNTIME_CLASS(CExtGridCellHeader)
                );
        pCell->TextSet("X");
        pCell->ModifyStyle(__EGCS_TA_HORZ_CENTER);
        pCell->ExtentSet(80);
    }
    RowAdd( 5, false );
    CExtGridCellVariant * pDataCell;
    for( i = 0; i < RowCountGet(); i++ )
    {
        for( j = 1; j < ColumnCountGet(); j++ )
        {
            pDataCell =
                STATIC_DOWNCAST(
                    CExtGridCellVariant,
                    GridCellGet(
                        j,
                        i,
                        0,
                        0,
                        RUNTIME_CLASS(CExtGridCellCurrency)
                        )
                    );
            pDataCell->ModifyStyle( __EGCS_NO_INPLACE_CONTROL );
            pDataCell->_VariantAssign( 0.0 );
        }
    }
    OnSwUpdateScrollBars();
}

Hi again,

I’m now having problems when selecting a row for which I need to scroll down the grid, if it’s my first selection it works fine, but when I select a visible row and then scroll down and select the last row it doesn’t highlight the selected row.

Thanks again for your help.

Would you send us the current version of the project so we can find out what’s wrong?

Hello,

How can I set cells to read-only ?

Example:

-----------------------------------------
| First column | second | third |
-----------------------------------------
| Read only | Editable | Editable |
-----------------------------------------
| Editable | Read only | Editable |
-----------------------------------------

And how to define header cell text for a fixed column ?

-----------------------------------------
| "First Header" | "second" | third |
-----------------------------------------
| Fixed Row 1 | some data | some data |
-----------------------------------------

Thanks a lot for your help

Regards,

Each cell in any of our grid windows can be made read-only independently from other cells. This ca be done applying the __EGCS_READ_ONLY style to the cell object (using CExtGridCell::ModifyStyle()). Please note that this style does not disable activation of the cell editor window, i.e. read-only cells use read-only inplace edit windows. This may be useful for copying cell text into clipboard. If you need to disable activation of the inplace editor at all, simply apply the __EGCS_NO_INPLACE_CONTROL cell style.

Hello all,

How can I do the following grid ?

------------------------------------------
| My cell "title" |
------------------------------------------
| Cell one | Cell two | Cell three |
------------------------------------------
| Cell one | Cell two | Cell three |
------------------------------------------
| My cell "title" |
------------------------------------------
| Cell one | Cell two | Cell three |
------------------------------------------

Thanks

Simon

The CExtGridWnd class implements a generic grid window with a fixed structure of columns and rows. It is not possible to make some cells cover the area of neighborhood cells. Such an effect is coded in the property grid control where the property category cells are stretched to cover two columns. The solution is based on the CExtGridWnd::OnGbwAdjustRects() virtual method which allows you to modify the rectangular area of grid cells and implemented in the CExtPropertyGridWnd class.

Hello,

I’ve created a derived class from CExtGridCell (CGridCellCategory) and overridden the CExtGridWnd::OnGbwAdjustRects method. But I can’t resize my cell on the full row size.

Does the newer version 2.53 permit it ?

When sorting is active on a column (the first), how can I limit the sorting action to all the rows but the CGridCellCategory row ? ( I want the CGridCellCategory row to stay at the bottom of the grid.)

Could you send me a sample ?

Thanks a lot.

I may have found a bug in CExtControlBar::ProfileBarStateLoad when there is an auto-hidden dynamic bar. I have modified the MDI sample to reproduce the behaviour, you can download it here: I have removed all the bars in the sample, added a single dynamic bar and two new menu items LoadState and SaveState. To reproduce the behaviour:
1) make the bar autohidden
2) save state
3) make the bar floating
4) load state

The bar looks auto-hidden, but if you right click on the caption bar, the "floating" menu item is enabled and the "Auto Hide" menu item is disabled.

Another minor problem (not related with the one above) that you can reproduce in the modified sample is the following:
1) make the bar an MDI document and de-maximize it
2) right click on the caption bar and select "Floating" to make it float again
3) look at the borders between the mini frame wnd and the inner edit control
4) resize the floating frame: you should see the borders be enlarged a bit

Your version of the MDI sample application needs to be modified. First of all, if you use resizable control bars with the auto-hide feature enabled, then the methods that update their state should be exactly like as follows (old lines of code are commented):

void CMainFrame::OnUpdateControlBarMenu(CCmdUI* pCmdUI)
{
//  CExtControlBar::DoFrameBarCheckUpdate( this, pCmdUI, true );
    CExtControlBar::DoFrameBarCheckUpdate( this, pCmdUI, false );
}
 
BOOL CMainFrame::OnBarCheck(UINT nID)
{
//  return CExtControlBar::DoFrameBarCheckCmd( this, nID, true );
    return CExtControlBar::DoFrameBarCheckCmd( this, nID, false );
}

Your methods that load/save the state are not completely correct. You load/save only the location of control bars and this is not correct in case of dynamic control bars. The state of the dynamic bar site should be loaded/saved at the same time. So, the code should include these two steps:

1) Call the CExtDynamicBarSite::StateLoad(), CExtDynamicBarSite::StateSave() or CExtDynamicBarSite::StateSerialize() method.

2) Call the CExtControlBar::ProfileBarStateLoad(), CExtControlBar::ProfileBarStateSave() or CExtControlBar::ProfileBarStateSerialize() method.

The CMainFrame::OnPersistenceLoadFromFile_Resizable() and CMainFrame::OnPersistenceSaveToFile_Resizable() methods in the MDI_DynamicBars sample application may be helpful in this regard.

We failed to reproduce the problem with border size of a floating mini frame window with a dynamic resizable control bar inside. Could you send us two screenshots demonstrating how the border changes.

Thank you for the quick reply. I modified the sample as you suggested:


void CMainFrame::OnTestLoadstate() {
    VERIFY(CExtDynamicBarSite::StateLoad("Test","Test","Test"));
    VERIFY(CExtControlBar::ProfileBarStateLoad(this,"Test","Test","Test"));
}

void CMainFrame::OnTestSavestate() {
    VERIFY(CExtDynamicBarSite::StateSave("Test","Test","Test"));
    VERIFY(CExtControlBar::ProfileBarStateSave(this,"Test","Test","Test"));
}

1) I noted that CExtDynamicBarSite::StateLoad fails with assert in CExtCmdIcon::IconCache::Serialize() if the video color depth is <32 bit.
2) A question: if the dynamic bar is persistent, is it really necessary to serialize its icon?

3) As to calling DoFrameBarCheckUpdate( this, pCmdUI, false ) and CExtControlBar::DoFrameBarCheckCmd( this, nID, false ), may I do that only when the bar is actually in autohide mode? (I like the possibility of showing/hiding the bar as the other normal control bars from the menu...)

4) Here are the two screen shots:

Before resize


After resize

It happens when you switch from mdi doc state to floating state

The icon serialization is needed because we suppose an icon may be changed on the fly according to the state of a particular task. It is especially reasonable if your application completely restotes the UI state.

The known problems with icons are fixed in Prof-UIS 2.53. The CExtCmdIcon class is rewritten from scratch and not based on HICON handles anymore. New icons are based on bitmaps with alpha channel and provide the Windows XP/Vista icon quality on any Windows OS. You can download the updated from our ftp site (or contact us via e-mail).

You can code your own OnBarCheck() and OnUpdateControlBarMenu() methods in the main frame window. These methods should analyze whether the control bar identifier corresponds to a particular control bar and whether it is in the auto hide mode. If the latter is true, the check-mark command style should not be used.Otherwise, it can be used for making control bar commands both showing and hiding the bar.

The border effect is really interesting. We will try to figure out what’s wrong and notify you additionally.

Thank you for your answers.

I understand the icon serialization is needed in general (of course you have a better idea about how your library is used by the various customers ;-) ). If possible, I suggest to add a flag do disable icon and title bar text serialization for those cases (like in my application) where the serialization is used only to save the layout, and the icon/text are always set by the application.

Acually I was already using a 2.53, but it was an older one. I downloaded the latest and I confirm the problem is now fixed. Furthermore, with the new icon classes, my application seems to use less GDI handles (probably due to the menu icons no longer being HICON) and this is very good, expecially for win98/me systems.

Yes, we can modify the CExtDynamicBarSite::StateSerialize() method so it will serialize icon/text using a new standalone method. This would allow you to override it.

Hello, here are two minor problems I incurred with the new icon classes in v2.53:

- icons with an odd size (e.g. 16x15) : ExtBitmap::AssignFromHICON( HICON hIcon ) does not work. I suggest to get the icon size always from the _iconInfo.hbmMask and not from the Hotspot.

- when a dynamic bar is in MDI child state and the MDI child is maximized, the icon displayed in the menu bar (the system menu of the child) has a black background (it seems the mask is not copied correctly); the same happens in the MDI tab icon. You can reproduce this problem by modifying the 16x16 icon associated to the dynamic bars in the MDI_DynamicBars sample so that it has some background pixels, then set a dynamic bar to MDI document state and maximize it.

First of all, plese let us whether where these problems can reproduced with Prof-UIS samples. Besides, we improved bitmap and icon classes, including the capatibilty of assigning a bitmap from an icon handle. Now it is possible to assign a Windows XP icon based on a 32-bit bitmap (with alpha channel). Please, download an updated Prof-UIS 2.53 from our ftp.

The first problem (but it is not a very important issue) does not need to be reproduced, just look at the implementation of bool CExtBitmap::AssignFromHICON( HICON hIcon ):

CSize _sizeIcon((INT)( (BYTE)(_iconInfo.xHotspot * 2 ) ),
     (INT)( (BYTE)(_iconInfo.yHotspot * 2 ) ));

it will be never able to correctly get an odd size (e.g. if the icon height is 15, it will set _sizeIcon.cy=14, since the hotspot y will be 7).


The second problem can be reproduced by modifying the 16x16 icon (IDR_MAINFRAME) associated to the dynamic bars in your MDI_DynamicBars sample: for instance make half of the pixels in the the icon background pixels, then set a dynamic bar to MDI document state, maximize it and look at the icon in the menubar on the left of the File menu.

We think we use the correct way of getting the icon size even with one pixel precision. Besides, this formula is not our idea. In fact, most of the icons have even sizes and this calculation does not bring a problem. The original toolbar common control is bitmap based. The HICON-related calculation will not affect. Here is the latest version of the CExtBitmap::AssignFromHICON() method which should not cause any problems:

 
bool CExtBitmap::AssignFromHICON( HICON hIcon )
{
    Empty();
    if( hIcon == NULL )
        return true;
ICONINFO _iconInfo;
    ::memset( &_iconInfo, 0, sizeof(ICONINFO) );
    if( ! ::GetIconInfo( hIcon, &_iconInfo ) )
        return false;
    ASSERT( _iconInfo.hbmColor != NULL || _iconInfo.hbmMask != NULL );
CSize _sizeIcon(
        (INT)( (BYTE)(_iconInfo.xHotspot * 2 ) ),
        (INT)( (BYTE)(_iconInfo.yHotspot * 2 ) )
        );
BITMAP _bmpInfo;
    ::memset( &_bmpInfo, 0, sizeof(BITMAP) );
    ::GetObject(
        (_iconInfo.hbmColor != NULL) ? _iconInfo.hbmColor : _iconInfo.hbmMask,
        sizeof(BITMAP),
        &_bmpInfo
        );
    ASSERT( _bmpInfo.bmWidth > 0 && _bmpInfo.bmHeight > 0 );
    if( _sizeIcon.cx == 0 || _sizeIcon.cy == 0 )
    {
        _sizeIcon.cx = (INT)_bmpInfo.bmWidth;
        _sizeIcon.cy = (INT)_bmpInfo.bmHeight;
    }
    ASSERT( _sizeIcon.cx > 0 );
    ASSERT( _sizeIcon.cy > 0 );
    if(       _bmpInfo.bmBitsPixel == 32
        &&    g_PaintManager.m_bIsWinXPorLater
        &&    CExtPaintManager::stat_GetBPP() >= 32
        )
    { // XP alpha icons under Windows XP or later + 32 bit desktop
        CExtImageList _il;
        if(    _il.Create(
                _sizeIcon.cx,
                _sizeIcon.cy,
                ILC_COLOR32,
                1,
                1
                )
            )
        {
            if( _il.Add( hIcon ) >= 0 )
            {
                IMAGEINFO _ii = { 0 };
                _il.GetImageInfo( 0, &_ii );
                ASSERT( _ii.hbmImage != NULL );
                ASSERT( _ii.hbmMask == NULL );
                if( ! FromBitmap(
                        _ii.hbmImage,
                        &_ii.rcImage,
                        false,
                        true
                        )
                    )
                    Empty();
                else
                {
                    bool bAssignedEmpty = true;
                    for( INT nY = 0; nY < _sizeIcon.cy; nY++ )
                    {
                        for( INT nX = 0; nX < _sizeIcon.cx; nX++ )
                        {
                            RGBQUAD _pixel;
                            VERIFY( GetPixel( nX, nY, _pixel ) );
                            if( _pixel.rgbReserved != 0 )
                            {
                                bAssignedEmpty = false;
                                break;
                            }
                        }
                        if( ! bAssignedEmpty )
                            break;
                    }
                    if( bAssignedEmpty )
                        Empty();
                }
                ::DeleteObject( _ii.hbmImage );
            }
        }
    } // XP alpha icons under Windows XP or later + 32 bit desktop
    if( IsEmpty() )
    { // old style icon
        if( _iconInfo.hbmColor == NULL && _iconInfo.hbmMask != NULL )
        {
            CRect rc( 0, 0, _sizeIcon.cx, _sizeIcon.cy );
            if( FromBitmap( _iconInfo.hbmMask, &rc, false, false ) )
            {
            }
            else
                Empty();
        }
        else if( _iconInfo.hbmColor != NULL )
        {
            if( FromBitmap( _iconInfo.hbmColor, false ) )
            {
                if( Make32( false ) )
                {
                    if( _iconInfo.hbmMask != NULL )
                    {
                        CExtBitmap bmpMask;
                        if(       bmpMask.FromBitmap( _iconInfo.hbmMask )
                            &&    bmpMask.Make32( false )
                            )
                        {
                            INT nX, nY;
                            for( nY = 0; nY < _sizeIcon.cy; nY ++ )
                            {
                                for( nX = 0; nX < _sizeIcon.cx; nX ++ )
                                {
                                    RGBQUAD _pixel;
                                    VERIFY( GetPixel( nX, nY, _pixel ) );
                                    COLORREF clrMaskPixel = bmpMask.GetPixel( nX, nY );
                                    if( clrMaskPixel == RGB(0,0,0) )
                                        _pixel.rgbReserved = 0xFF;
                                    else
                                        _pixel.rgbReserved = 0x0;
                                    VERIFY( SetPixel( nX, nY, _pixel ) );
                                }
                            }
                        }
                        else
                            Empty();
                    }
                }
                else
                    Empty();
            }
        }
    }
    if( _iconInfo.hbmColor != NULL )
        ::DeleteObject( _iconInfo.hbmColor );
    if( _iconInfo.hbmMask != NULL )
        ::DeleteObject( _iconInfo.hbmMask );
    OnContentChanged();
bool bIsEmpty = IsEmpty();
    return ( ! bIsEmpty );
}

Yes. I agree that icons should have even sizes, so it is not a problem, thank you.

What about the second problem? Are you able to reproduce it as I described?

Dear Support,
I’ve read your article "How to insert menu items at run time?", and tried to use it to change items in a submenu. I was thinking that since submenu is a popupmenu as well, I would get the CExtPopupMenuWnd::g_nMsgPrepareMenu message for the submenu as well...

But no. So to find out if I’m in the right menu, I guess I have to go through all the menuitems, check if they are of type TYPE_POPUP, and if so, go into that submenu to check if it’s the one I’m looking for. This works as long as I know that the submenu I’m looking for is the child-popup menu of a main popup menu... But how could I make it work for a menu that I don’t know nothing of? It could be anywhere in the tree of submenus.

I’m hoping not sending that messgae for the submenus is only a bug.

Could you please advise? Thank you:
Chris.

Starting from Prof-UIS 2.33, there is a CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel registered windows message. This message is also sent by the pop-up menu before it appears on the screen. This message has the same parameters but it is sent separately for each pop-up menu level.

Following the above advice, changing the submenu at run-time is working well for me, except for one thing. The menu is not immediately updated. The user must dismiss the menu, and display the menu again before the menu shows the menu items that have been inserted and removed with ItemInsert and ItemRemove.

I’m handing the registered message:
ON_REGISTERED_MESSAGE(CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel, OnExtPrepareOneMenuLevel)

In the handler, I basically do this:

LRESULT CMainFrame::OnExtPrepareOneMenuLevel(WPARAM wParam, LPARAM lParam)
{
CExtPopupMenuWnd::MsgPrepareMenuData_t * pData =
reinterpret_cast< CExtPopupMenuWnd::MsgPrepareMenuData_t * > (wParam);
ASSERT( pData != NULL );
CExtPopupMenuWnd * pPopupMenu = pData->m_pPopup;
LPCTSTR lpszCommandProfileName
= g_CmdManager->ProfileNameFromWnd(pMainFrame->m_hWnd );
CExtCmdItem * pCmdItem = g_CmdManager->CmdGetPtr(lpszCommandProfileName, nCommandID);
if (pCmdItem == NULL)
{
pCmdItem = g_CmdManager->CmdAllocPtr(lpszCommandProfileName, nCommandID);
}
pPopupMenu->ItemInsert(nDynamicCommandID, -1);
if (pCmdItem != NULL && lpszMenuItemText != NULL)
{
pCmdItem->m_sMenuText = "This is a dynamic menu item";
}

...

pData->m_bMenuChanged = true;
return 1;
}

I thought I had found the missing detail when I read about pData->m_bMenuChanged = true in a Prof-UIS article, but that didn’t solve the problem.

What should I do to make the menu immediately show the changes?

Cheers
-- Mark

The CExtPopupMenuWnd::ItemInsert() method inserts a pop-up menu item which is based on the command description in the Command Manager. If you insert command items which do not need a reference to the command manager and which do not need to be updated with the MFC command updating mechanism, you can use the CExtPopupMenuWnd::ItemInsertCommand() method. Please try this method for building your custom pop-up menu. Otherwise you need to register your commands before building any pop-up menu.

I found out what the problem was and fixed it. I had already created the CExtCmdItems beforehand; so that was not the problem.

The problem is that the following two statements were in the wrong order:

pPopupMenu->ItemInsert(nDynamicCommandID, -1);
if (pCmdItem != NULL && lpszMenuItemText != NULL)
{
pCmdItem->m_sMenuText = "This is a dynamic menu item";
}

They should be:

if (pCmdItem != NULL && lpszMenuItemText != NULL)
{
pCmdItem->m_sMenuText = "This is a dynamic menu item";
}
pPopupMenu->ItemInsert(nDynamicCommandID, -1);

The ItemInsert function sets menu item text according to the CExtCmdItem::m_sMenuText, which needs to have been set before the call to ItemInsert rather than afterwards.

Thanks!
-- Mark

Is there a way to have CExtResizableDialog not painting the background with a gradient (with VS 2005 visual style active) but with a solid color or a bitmap ?

You can just use CDialog rather than CExtResizableDialog. If you need to add anchoring support, simply apply the CExtWA template to the CDialog class.

That’s not exactly what I was looking for. I omitted an important detail; I need the gradient background when the application runs under Windows XP, but I don’t want it when it runs under Windows 2000 and to make the change you propose I have to change too much. I thought there was a property or method that could have made it much easier.

Thanks

Hi. Is there a way to have the description pane show a description even though no item in the CExtPropertyGridCtrl is selected?

I build a MDI-Application with the Prof-UIS-Wizzard (all standard except "linking with MFC static Lib")
When I try to execute I get the following ASSERT:

map_pp.cpp
Line 215

Starting point for this exception is the cunstructor of CExtPopupMenuSite
line 138 in extpopupmenuwnd.cpp

CExtPopupMenuSite CExtPopupMenuSite::g_DefPopupMenuSite;

Any idea...

There is not enough information in your message to fing out what’s wrong with the code. We need to know which version of Prof-UIS and which Visual Studio you are using? Of course, it will be of great help if you will send this project to us.

Please note that if you are using Prof-UIS 2.52 and a static configuration, then you need to include the following line in your *.rc2 file:

/////////////////////////////////////////////////////////////////////////////
// Add manually edited resources here...
 
#if ( !(defined _AFXDLL && !defined __STATPROFUIS_WITH_DLLMFC__) )
 #include <Resources/Resource.rc>
#endif

The static linking is described in the FAQ How to link statically with Prof-UIS?.

We have found a problem when loading application state from a file (your StateInFile sample application). By doing the following, you will notice that the state of one of the 2 control bars will not get loaded correctly.

- Delete HKEY_CURRENT_USER\Softaware\Foss\StateInFile to get a fresh start.
- Open StateInFile example
- Save to state1
- Dock bar 0 to bottom with bar 1 (tabbed)
- Make sure bar 1 visible in the tabs
- Save to state2
- Undock bar 0 and leave it floating.
- Save to state3

- Load state2
- Load state3

State 3 is supposed to have bar 0 floating and visible, but it’s not visible anywhere on the screen.

Thank you for the bug report. We fixed this and can provide you with the updated source code on your request.

The latest code has fixed the initial problem, but we now have another:

- Delete HKEY_CURRENT_USER\Softaware\Foss\StateInFile to get a fresh start.
- Open StateInFile example
- Save to state1
- Dock bar 0 to bottom with bar 1 (tabbed)
- Make sure bar 1 visible in the tabs
- Save to state2
- Undock bar 0 and leave it floating.
- Save to state3

- Load state2
- Load state3

- Dock bar 0 to bottom with bar 1 (tabbed)

Bar 0 is not visible anymore. It seems it was hidded after it was docked.

Thank you for the bug information. We have fixed it. Please download the source code from our ftp again.