Forum

Thanks for adding the new __ETWS_EX_CLOSE_ON_TABS and __ETWS_EX_CLOSE_ON_SELECTED_ONLY Tab Control options. I can’t find any documentation for these in the Help though. They are not listed in the CExtTabWnd Constants section.

I did find them used in the DrawCli sample app.

Neville http://www.surfulater.com

All the samples contain the UI theme switcher toolbar but none seem to make the theme setting persist. How can I do it?

Thanks

David, I’ve just implemented the code described here: http://www.prof-uis.com/Forum_View.aspx?CID=40&M=10177&s=CExtThemeSwitcherToolControlBar and it works just fine. Make sure you include the call to ar.Flush() as mentioned.

It would be nice if there were Prof-UIS functions to do this for us.

Neville http://www.surfulater.com

Is there an easy way to place a dialog resource template in a CExtControlBar?
Maybe also an example of a propertypage like dialog (tab control with
a changing dialog page).

best regards,
Alexander

Here is the FAQ article that may be helpful:

I know how to add a resizable control bar to my program but I do not know how to add a dialog into it

As for the tab control, you could use CExtTabPageContainerWnd. You can see how to use it in the ProfUIS_Controls sample (the page Tab Containers).

Thanks for the reference.
I tried it, as far as I understand. The text is a bit contradictionary.
It says: "dialog window inside the control bar".
The example code:
if( !m_wndInBarDlg.Create(
CYourDialog::IDD,
&m_wndResizableBar
)
)
{
TRACE0("Failed to create m_wndInBarDlg\n");
return -1;
}
m_wndInBarDlg.ShowSizeGrip( FALSE );

I think your code assumes that it is outside the
and m_wndInBarDlg refers to the resizable control bar.

When I implement it in a CExtControlBar::CreateDlgCtrlBar function,
The dialog shows at application start-up, as a regular modeless dialog.
It seems to ignore that I gave it the CExtControlBar as a parent window.

My code is:
int CDlgCtrlBar::CreateDlgCtrlBar(CFrameWnd* pParentWnd, UINT nDialogTemplateID)
{
    if(    !Create(
        NULL, // _T("Optional control bar caption"),
        pParentWnd,
        ID_VIEW_RESIZABLEBAR_DLG,
        WS_CHILD|WS_VISIBLE|CBRS_TOP|CBRS_GRIPPER
        |CBRS_TOOLTIPS
        |CBRS_FLYBY
        |CBRS_SIZE_DYNAMIC
        |CBRS_HIDE_INPLACE
        )
        )
    {
        TRACE0("Failed to create m_wndResizableBarDlg\n");
        return -1;        // fail to create
    }

    if (!m_Dialog.Create(nDialogTemplateID, this))
    {
        TRACE0("Failed to create the Dialog\n");
        return -1;        // fail to create
    }

    m_Dialog.ShowSizeGrip(FALSE);

    EnableDocking( CBRS_ALIGN_ANY );
    DockControlBar(AFX_IDW_DOCKBAR_RIGHT, 2, pParentWnd);
    return 0;
}

Any sugestions?
Maybe the example can be made more clear with actual code.

Best regards,
Alexander.

can you give me a Sample from a CExtGridWnd in virtual mode without ado? I only want see what I must change in my CExtGridWnd class, so that it work in virtual mode...

Who can I add a Row in the Grid?
I have a virtual grid now with 10000 rows... When i press a Button until my Grid, i want to add a row...

In a normal grid i make it so:

" mygrid.RowAdd( 1L, true );
LONG nRowNo = mygrid.RowCountGet()-1;

CExtGridCellStringDM * pCellText =
    STATIC_DOWNCAST(
    CExtGridCellStringDM,
    mygrid.GridCellGet(
    0L,
    nRowNo,
    0,
    0,
RUNTIME_CLASS(CExtGridCellStringDM)
    ));
    
pCellText->TextSet( "this is a test" );
"

so, when i make it in the virtual grid, my App crashs in the position with "mygrid.RowAdd( 1L, true );"

The cacheable grid window is based on the external data and you cannot insert rows into any kind cacheable grids. You can only modify the external data source and invoke grid’s SiwFireCacheChanging() method to refresh the cacheable grid including its scroll bars.

thanks...
i hope that sorting is no problem... ;)

Thinking about sorting a little more: Having the grid do the sorting won’t work in case of virtual grid because any given time the grid only knows about the cached data inside of it, but not all the data. I think sorting has to be done inside Cache method, having the grid do only the presenting of the data and no computing at all.

Does it make any sense? :)

Chris

this work good, thanks...

only two more questions...

how can i sort now?

i have the following Method, but it not work anymore...

SortGrid(int iCol, bool bAsc)
{
    CExtGridDataSortOrder gdsoColumns;
    CExtGridDataSortOrder::ITEM_INFO _soii(
     iCol, // sort first column
        bAsc // true - ascending sort order, false - descending
);
    gdsoColumns.m_arrItems.Add( _soii );

    m_MyGrid.GridSortOrderSetup(
        false, // true - sort colums, false - sort rows
        gdsoColumns,
        false,
        false, // invert sort order
        true
    );
}

and, how can i deactivate the drag and drop function on the header?
your sample crash if i use the drag an drop function...

thank you

The cacheable grid control is based on external data and it does not know how to sort the data or how to re-arrange columns in the external data source. You should handle clicks on header cells by overriding the CExtGridCell::OnClick() or CExtGridBaseWnd::OnGbwAnalyzeMouseClick() virtual methods and implementing your own data sorting algorithm. The header cells allow you to display the built-in sort arrows using __EGCS_SORT_ARROW and __EGCS_SORT_DESCENDING cell styles. The drag-and-drop implementation should be based on the CExtGridWnd::OnGridOuterDragComplete() and CExtGridWnd::OnGridOuterDragOut() virtual methods without invoking parent class methods.

The answer to your second question is easy: you have to call BseModifyStyleEx( 0L, __EGBS_BSE_EX_DRAG_COLUMNS|__EGBS_BSE_EX_DRAG_ROWS);

Sorry, I don’t have any idea on your sorting problem.

Dear Support,

I’m trying to make a simple grid to look like a ListBox. For this purpose I made the following class:

class CExtFormListBox : public CExtGridWnd
{
public:
	int AddString(LPCTSTR lpszItem) 
	{ 
		if (ColumnCountGet() <= 0) ColumnAdd(1, false);
		RowAdd(1, false);
		int iNewIndex = RowCountGet()-1;
		GridCellGet( 0, iNewIndex, 0, 0, RUNTIME_CLASS(CExtGridCell) )->TextSet(lpszItem);
		BestFitColumn(0); 
		return iNewIndex;
	}
};

I only call this AddString function from other place, no other type of initialization is done. My problem is with BestFitColumn. Around the end of this BestFitColumn method there’s this code segment:

				INT nExtentMin, nExtentMax;
				pCell->ExtentGet( nExtentMin, -1 );
				pCell->ExtentGet( nExtentMax, 1 );
				if( nBestFitExtent < nExtentMin )
					nBestFitExtent = nExtentMin;
				if( nBestFitExtent > nExtentMax )
					nBestFitExtent = nExtentMax;
				pCell->ExtentSet( nBestFitExtent );

Before the code gets to this part, nBestFitExtent is 8 (measured by the text in it). Both ExtendGet calls return false and both nExtentMin and nExtentMax stays to be 0xcccccccc. In my case this results in setting 0xcccccccc in ExtentSet and I have 0 wide cells, even though width should be 8. Could you fix this code and check return code of ExtentGet?

Thank you:
Chris

The best fit feature requires an outer header row (for instance at the top) and header cells in it (for instance CExtGridCellHeader). You can hide the header row if needed (set the zero height with CExtGridWnd::OuterRowHeightSet()).

The best fit feature may make your list box like window having the horizontal scroll bar. We guess the automatic proportional resizing of the column can be used instead.

I want to have horizontal scrollbar and also vertical (when needed). With outer header row I could get BestFitColumn to work. For testing purposes I didn’t set the outer row’s height to zero yet, so I can see the column is as wide as I’d like it to be. But still, i have neither vertical, nor horizontal scrollbar. I even called OnSwRecalcLayout( true ); OnSwUpdateScrollBars(); OnSwDoRedraw(); , but still no scrollbar (actually I stepped into BestFitColumn while debugging, and these above methods are called from there as well). I checked available styles, methods, overridables in all classes CExtGridWnd is derived from, tried setting WS_VSCROLL|WS_HSCROLL styles, still no luck. What am I missing?

Thank you:
Chris

You don’t need the WS_HSCROLL|WS_VSCROLL styles. You should apply the __ESIS_STH_PIXEL|__ESIS_STV_ITEM styles using CExtScrollItemWnd::SiwModifyStyle(). This will make your grid pixel-by-pixel scrollable horizontally and item-by-item scrollable vertically. You can send us the source code of your grid so we can find out what’s wrong.

Hi,

I’m having some problem with CExtPopupMenuWnd since I updated to version 2.62.

I’m loading my proper CMenu, doing operations (hide or disable items) on it and then I create a CExtPopup to track it :

CExtPopupMenuWnd * pPopup = new CExtPopupMenuWnd;

pPopup->CreatePopupMenu(GetSafeHwnd());

pPopup->UpdateFromMenu( GetSafeHwnd(),
Menu,
true, // bPopupMenu
true, // bTopLevel
true // bNoRefToCmdMngr
);
pPopup->TrackPopupMenu(TPMX_LEFTALIGN, point.x, point.y);

Some of my menu commands open a simple CDialog. But in this dialog, all my keyboard actions are ignored. I can’t type in an Edit for exemple. The caret is here, but noting append when I type a key.

If I set bNoRefToCmdMngr to false, the CDialog is OK, but if I disable commands at runtime in my Popup Menu, it’s ignored and all the items are enabled.

Do you know how to solve this problem, please ?
Thank you in advance.

Aurelien Loizeau.

Hi, it’s done, I send the project by mail yesterday.

Thank You.

Aurelien

In fact I spoke too quickly ˆˆ

I’ve updated my small exemple (http://aurelien.loizeau.free.fr/profuis/PopupMenu.rar).

I have now a problem if I want to open another popup menu in the sub dialog.
If the sub dialog is called by clicking the button, everything is fine. But if the sub dialog is opened via the popup menu -> the new popup menu called by a right click in the subdlg is not working.

This problem is hapening even with the fix you gave me above.

Thanks for your help again.

AurA©lien Loizeau

Could you please send this project to us at support@prof-uis.com?

Thank you, works great now.

Hi,

I’ve uploaded a very small example here : http://aurelien.loizeau.free.fr/profuis/PopupMenu.rar

Just right click on the dialog and open the subdlg via the popup menu -> the subdlg does not get the inputs (try to type text in the edit).

If bNoRefToCmdMngr is passed to false in the UpdateFromMenu call, the problem is solved.

Thank you

AurA©lien Loizeau

Thank you for reporting this issue. To fix it, please update the CExtPopupMenuSite::_Done() method in the ..\Prof-UIS\Src\ExtPopupMenuWnd.cpp file:

void CExtPopupMenuSite::_Done()
{
    ASSERT( ! m_bShutdownMode );
    if( m_pWndToolTip != NULL )
        m_pWndToolTip->Hide();
    m_bShutdownMode = true;
    m_pWndCapture = NULL;
    m_pWndAnimation = NULL;
    m_lpnResultCmdID = NULL;
    _Hook( false );
    if( m_pTopMenu != NULL )
    {
        ASSERT( m_pTopMenu->m_bTopLevel );
        if( ! m_pTopMenu->_IsFadeOutAnimation() )
        {
            VERIFY( m_pTopMenu->_BuildItems( NULL, true ) );
            if(        m_pTopMenu->GetSafeHwnd() != NULL
                &&    ::IsWindow( m_pTopMenu->GetSafeHwnd() )
                )
            {
                CExtControlBar::stat_SetMessageString(
                    m_pTopMenu->GetOwner()
                    );
                m_pTopMenu->DestroyWindow();
                MSG msg;
                while( ::PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) )
                {
                    if( WM_MOUSEFIRST <= msg.message && msg.message <= WM_MOUSELAST )
                    {
                        ::PeekMessage( &msg, NULL, msg.message, msg.message, PM_REMOVE );
                        continue;
                    }
                    if( ! ::AfxGetThread()->PumpMessage() )
                        break;
                }
            }
            ASSERT( m_pTopMenu->GetSafeHwnd() == NULL );
            delete m_pTopMenu;
        }
        m_pTopMenu = NULL;
    }
    __VPC_VERIFY_0;
    m_bShutdownMode = false;
}

Hi,
I have three ribbon groups in a bar the code for the customers group is below, it should have one large icon and two small. It works sometimes but other times they are all large, can you tell me what I am doing wrong?

CExtRibbonNodeGroup * pRibbonGroup = new CExtRibbonNodeGroup( ID_RIBBON_GROUP_CUSTOMERS );
    pRibbonGroup->SetTextInToolbar( _T("Customers") );

    
    CExtRibbonNode * pNodeAddCustomers =
            new CExtRibbonNode( ID_ADD_CUSTOMER, 0, NULL, 0, _T("Add Customer") );
        pNodeAddCustomers->RibbonILE_RuleArrayGet().RemoveAll();
        HICON hIcon=(HICON)::LoadImage(::AfxGetResourceHandle(),MAKEINTRESOURCE(IDI_ADDCUSTOMER),IMAGE_ICON,24,24,0);
        pNodeAddCustomers->m_iconBig.AssignFromHICON(hIcon,false);
    
    pRibbonGroup->InsertNode(
            NULL,
            pNodeAddCustomers
            );

    pRibbonGroup->InsertNode(
        NULL,
        new CExtRibbonNode // separator
        );

    CExtRibbonNode * pNodeEditCustomer =
            new CExtRibbonNode( ID_EDIT_CUSTOMER, 0, NULL, 0, _T("Edit Customer") );
        pNodeEditCustomer->RibbonILE_RuleArrayGet().RemoveAll();
        hIcon=(HICON)::LoadImage(::AfxGetResourceHandle(),MAKEINTRESOURCE(IDI_EDITCUSTOMER),IMAGE_ICON,16,16,0);
        pNodeEditCustomer->m_iconSmall.AssignFromHICON(hIcon,false);
        pNodeEditCustomer->RibbonILE_RuleArrayGet().Add(__EXT_RIBBON_MAKE_RULE_ARRAY_ENTRY(__EXT_RIBBON_ILE_MAX,__EXT_RIBBON_ILV_SIMPLE_SMALL,true));
        pRibbonGroup->InsertNode(
            NULL,
            pNodeEditCustomer
            );

    CExtRibbonNode * pNodeDeleteCustomer =
            new CExtRibbonNode( ID_DELETE_CUSTOMER, 0, NULL, 0, _T("Delete Customer") );
        pNodeDeleteCustomer->RibbonILE_RuleArrayGet().RemoveAll();
        hIcon=(HICON)::LoadImage(::AfxGetResourceHandle(),MAKEINTRESOURCE(IDI_DELETECUSTOMER),IMAGE_ICON,16,16,0);

        pNodeDeleteCustomer->m_iconSmall.AssignFromHICON(hIcon,false);
        pNodeDeleteCustomer->RibbonILE_RuleArrayGet().Add(__EXT_RIBBON_MAKE_RULE_ARRAY_ENTRY(__EXT_RIBBON_ILE_MAX,__EXT_RIBBON_ILV_SIMPLE_SMALL,true));
        pRibbonGroup->InsertNode(
            NULL,
            pNodeDeleteCustomer
            );
    

        return pRibbonGroup;



Regards,
Eddie

We are in the process of converting applications created prior to securing the ProUI library.
One of the initial efforts is to change the standard ’CToolBar’ controls to the ’CExtToolControlBar’. After making the modifications recommended in the Pro documentation (e.g. renaming the classes, and modifying the Create call), the tool bar is created, and does respond to user clicks with the appropriate messages. However, the bit maps are not displayed. If the mouse hovers over where the bitmap ’should be’, the area is hilighted, and the tool tip is presented......just no image. These tool bars were created in the usual manner through Visual Studio, and are loaded via the LoadToolBar method. All Pro calls return success.

the g_CmdManager->UpdateFromToolBar is called automatically from within LoadToolBar, but this did provide the neccessary clue. This automatic call was failing (without being reported). The key to getting it to work was the call

    g_CmdManager->ProfileSetup( __PROF_UIS_PROJECT_CMD_PROFILE_NAME, GetSafeHwnd() );

in the same method that created the tool bar. In this case that method was CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)

Thank you, the problem is now solved.

We guess there must be something incorrect with the sequence of initialization calls the CMainFrame::OnCreate() method. Would you send the source code for your main frame window to us at support@prof-uis.com so we can help you out?

While debugging my MDI app and comparing my code against some samples I see that the samples derive the app’s CMainFrame from
CExtNCW < CMDIFrameWnd >. What functionality does the template offer? Can’t find any doc’s on it.

I’ve implemented a CExtResizableDialog with a custom control. The Class of the custom control is set to "ProfUIS-ScrollItemWindow".


in header file:
    CExtTreeGridWnd _reportsTree;

In DoDataExchange(), I do this:

    DDX_Control(pDX, IDC_REPORTS_TREE, _reportsTree); // IDC_REPORTS_TREE is the ID for the custom control on the dialog resource


I found some sample code in the prof ui help file that basically did this to add the first item to the tree:

    HTREEITEM htiRoot = _reportsTree.ItemGetRoot(); // Very top root item, which is invisible
    HTREEITEM htiCurrent = _reportsTree.ItemInsert( htiRoot, ULONG(-1) );
    ASSERT ( htiCurrent != NULL );
    CExtGridCellCheckBox * pCell = (CExtGridCellCheckBox *)
        _reportsTree.ItemGetCell(htiCurrent, 0,0,RUNTIME_CLASS(CExtGridCellCheckBox)); //Get the string cell in column 0
    ASSERT ( pCell != NULL ); // this always asserts
    pCell->TextSet(L"My Checkbox");


However, pCell is always NULL. htiCurrent has a valid HTREEITEM though.

What am I doing wrong?

Thanks,
Scott

P.S. This is with 2.61

Thank you, that did help some. However, the column width was very small and cut off most of the text for all my checkboxes. I finally discovered the DefaultColumnWidthSet() method which solved that.

I’ve also had problems with ItemGetFirstChild(root), which always returns NULL. However, ItemGetChildAt(root, 0) works fine.


My other question is how easy is it to add tooltips for each of my checkboxes (e.g., show a tooltip when the user selects a HTREEITEM).

Thanks,
Scott

We are sorry for the delay with this reply. You should add one outer header row at the top using CExtGridWnd::OuterRowCountTopSet() and instantiate a CExtGridCellHeader cell in it. This will allow you to specify the column width using the ExtentSet() method of the header cell. You could also use the proportional column resizing of the grid window so that the column(s) can automatically be stretched to grid’s width. You can do this by applying the __EGBS_BSE_EX_PROPORTIONAL_COLUMN_WIDTH style using the CExtGridWnd::BseModifyStyleEx() method. The proportional width of the particular column can be specified with ExtentPercentSet() of the column’s header cell. You can hide the header row by setting its height to zero with the CExtGridWnd::OuterRowHeightSet() method.

The bug related to the ItemGetFirstChild() method was fixed in Prof-UIS 2.62. The CExtGridBaseWnd::EnableExpanding() method allows you to turn on the expand tip for grid cells.

Dear Support,
The same problem of calling KillBar for Tabbed bars happens when they are docked side-by side.
Please fix this bug as well.
Regards,
Ron.

Dear Support,
Were you able to reproduce?
Any plans on fixing this bug?
Regards,
Ron

I upgraded from 2.61 to 2.62 and my dialogs no longer display CExtCheckBox controls inside a CExtGroupBox control. However, if I remove the     DDX_Control(pDX, IDC_CHECK1, m_check1); that associates the checkbox with your CExtCheckBox class, the check box displays (although not painted correctly).

Also, I’m not sure why you guys changed this, but I can no longer just copy the Include directory into my projects. Several header files now include other header files under the Src directory, which requires me to copy those headers as well into a Src directory at the same level. This is rather sloppy and I would like to see this fixed next version.

I’m trying to create a CExtEdit control dynamically in the OnInitDialog of a CExtResizableDialog. It didn’t act as expected, so I tried it in one of your samples as well (CompoundProperties), with same result. I can see the control appearing, but when hovering over it with the mouse, or putting the focus into it, the editbox doesn’t have any kind of border appearing (it should be a border consistent with the selected paintmanager). This is the code I added to your sample:
MainDlg.h:

	CArray <CWnd *, CWnd *> m_vWnds;

MainDlg.cpp:

CMainDlg::~CMainDlg()
{
	for (int i = 0; i < m_vWnds.GetSize(); i++) {
		if(m_vWnds[i] != NULL) delete m_vWnds[i];
	}
	m_vWnds.RemoveAll();
}
...
BOOL CMainDlg::OnInitDialog() 
{
	...
	CRect rect(700, 472, 800, 492);
	ScreenToClient(&rect);
	CExtEdit *pEdit = new CExtEdit;
	pEdit->Create(WS_VISIBLE|WS_CHILD|WS_TABSTOP|ES_AUTOHSCROLL, rect, this, IDC_EDIT1);
	pEdit->ModifyStyleEx(0, WS_EX_CLIENTEDGE|WS_EX_NOPARENTNOTIFY);
	m_vWnds.Add(pEdit);
 
	AddAnchor( IDC_OBJECT_CANVAS, CSize(0,0), CSize(60,100) );
	AddAnchor( IDC_PROPERTY_GRID_CTRL, CSize(60,0), CSize(100,100) );
	...
}

I got the applied styles from another CExtEdit created throught the .rc file (, which works fine). Could you give me any hint on what initialization I’m missing?

Thank you,
Chris

Please replace the following line

pEdit->ModifyStyleEx( 0, WS_EX_CLIENTEDGE|WS_EX_NOPARENTNOTIFY );

with this one

pEdit->ModifyStyleEx( 0, WS_EX_CLIENTEDGE|WS_EX_NOPARENTNOTIFY, SWP_FRAME_CHANGED );

Am I right to assume that for proper initialization I also need to call SetFont for this dynamically created editbox (and for any dynamically created control)?

By default, the newly created windows have the System font, which does not look good. We recommend you assign the following font:

( (HFONT) ::GetStockObject( DEFAULT_GUI_FONT ) )

Dear Support,

I have reported a long time a go a bug regarding the shrinking width of bars when tabbed.
It seems that this bug is back.
This is the scenario:
1) Dock two bards tabbed.
2) Drag the bottom border to make the bars higher (drog down)
3) Notice that the width of the bars is shrinking by one pixel
4) Repeat 2 (both up and wod dragging)
5) Each drag shrinks the width by one pixel.

Please note that the shrinking is done at the beginning of the drag operation.

Regards,
Ron.

Dear Support,
Still waiting any kind of respose.
Regards,
Ron.

Dear Support,

Is this fix available?
When is the next release scheduled?

Regards,
Ron.

Dear support,
I have further explored my my with tabbed docked bars that are closed using KillBar.
To recap, the scenario is two docked bars tabbed together, and when the ’X’ is pressed they override their NcButtons_HandleClick and call KillBar on thenselves.

My finding is as follows:
When there are two docked bar, the first to get closed works fine, it is closed, killed and destroyed.
When the second is closed, and i get into CExtDynControlBar::NcButtons_HandleClick i see that tab control is still active, even though in the display there is one bar now, what happens is that the line
pTabbedBar->GetBarAt( nTabSel, true );
Return -1 because there is no real tab control anymore, because of that pActiveInTabbedBar is null, and the docked bar virtual function is not called.

Please re-create according to the steps i sent you yesterday, and fix this problem.

Regards,
Ron.

Dear Support,

I have made some more tests on ’normal’ bars (without calling the KillBar)
I found out that when you dock two bards tabbed together, and then close one of the bars, even though there is only one bar now displayed, you still use the CExtDynTabControlBar, and it behaves OK. I can only guess that the problem is in the ordering of things in the CExtDynTabControlBar when KillBar is called. Please also note that i use g_bCloseOnlyOneBarInTabGroup.

I would really appreciate it if we could close this bug today so that we will be able to have the ability to release a version beginning of next week.

Best Regards,
Ron.

From further debugging, I can assume that the problem is that m_nSelIndex of the CExtTabWnd class is not updated correctly when the first bar was destroyed.

After exploring more, i see that the bug is probably in the KillBar function, it calls
pTabbedBar->RemoveSelFromSwitcher();
which leaves the bar control with selected tab -1, which of course does not make sense.

The function KillBar that you directed me towards was not intended to work with tabbed bars i guess, so this is why all this mess occurred.

Dear support team,

I am using a CExtPropertyGridCtrl with about 60 property items in about 12 categories. The property items have dependencies, i.e. if for example the checkbox item X is not checked, then the colour items A, B and C have to be read only.
I implemented this behaviour in the following way:

I wrote a class derived from CExtPropertyValue for the checkbox item. I overwrote the Apply method this way:

    CExtPropertyValue::Apply(pValue);

    CExtGridCellBool * pValueBool =
        static_cast<CExtGridCellBool*>(pValue);
    bool newValue = pValueBool->DataGet ();
    
// For each dependent item
    CExtGridCell * cell = dependentItem->ValueActiveGet();

    if (newValue == TRUE)
    {
        // if checkbox checked -> remove style __EGCS_READ_ONLY
        cell->ModifyStyle (0L, __EGCS_READ_ONLY);
    }
    else
    {
        // if checkbox not checked -> add style __EGCS_READ_ONLY
        cell->ModifyStyle (__EGCS_READ_ONLY, 0L);
    }
// For each dependent item end


// Synchronize the property grid to apply the changes
    m_ptrPGC->SetRedraw( FALSE );
m_ptrPGC->PropertyStoreSynchronize();
m_ptrPGC->SetRedraw( TRUE );
    m_ptrPGC->RedrawWindow( NULL, NULL, RDW_INVALIDATE|RDW_ERASE|RDW_ALLCHILDREN );


When I click the checkbox of the property item I get the following result:
The application takes a noticeable break.
The grid window scrolls to the middle position.
The checkbox of the property item gets painted according to its now state
The dependent items change from read only to read write or vice versa according to the new state.

How can I prevent the property grid window from scrolling to the middle after the synchronization with the property store? I would like it to remain in its scroll position.

The call off PropertyStoreSynchronize causes a noticeable delay in the application. It seems that the whole property store is synchronized with the property grid. Is there another way to apply the new state (RW or RO) of the dependent items to the property grid?

With best regards Andreas Werner

I can only say sure about the scrolling issue. PropertyStoreSynchronize removes all cells from every grid window and inserts them again. This means that the last category will be the focused cell after the synchronization. You have to set the focus back to the cell that was changed last. That will solve the scrolling problem.

	CExtPropertyGridWnd * pActiveGrid = m_ptrPGC->GetActiveGrid();
	CExtPropertyItem *pFocusedItem = pActiveGrid->PropertyItemFromTreeItem(pActiveGrid->ItemFocusGet());
	m_ptrPGC->SetRedraw( FALSE );
	m_ptrPGC->PropertyStoreSynchronize();
	HTREEITEM hTreeItem = pActiveGrid->PropertyItemToTreeItem( pFocusedItem );
	pActiveGrid->ItemFocusSet( hTreeItem );
	m_ptrPGC->SetRedraw( TRUE );
	m_ptrPGC->RedrawWindow( NULL, NULL, RDW_INVALIDATE|RDW_ERASE|RDW_ALLCHILDREN );

Although CExtPropertyGridWnd has a PropertyStoreSynchronizeOneLevel method, it wants to insert the PropertyItem given as parameter, and asserts if finds the propertyitem already in the grid. So I’m not sure about how to solve your other problem.

In addition to what Chris advised, we would like to add the following. The CExtPropertyGridCtrl::PropertyStoreSynchronize() method completely rebuilds the contents of all tree grids inside the property grid control. You should not use this method in your implementation of dependent property values. Use direct access to the tree grids instead. Please note that a property value inside the property store keeps two grid cell objects corresponding to the initial and current satets of the value. Each tree grid contains only one copy of the current (active) cell for each propery value. For example you have some property value in the property store:

CExtPropertyGridCtrl & _PGC = . . .
CExtPropertyValue * pPropertyValue = . . .
CExtGridCellBool * pValueBool = STATIC_DOWNCAST( CExtGridCellBool, pPropertyValue->ValueActiveGet() );
bool newValue = pValueBool->DataGet();
. . .

The code below will assign all copies of pValueBool grid cell in all tree grids inside the property grid control:

CTypedPtrArray < CPtrArray, CExtPropertyGridWnd * > arrGrids;
    _PGC.OnPgcQueryGrids( arrGrids );
INT nGridIdx = 0, nGridCount = INT( arrGrids.GetSize() );
    for( ; nGridIdx < nGridCount; nGridIdx ++ )
    {
        CExtPropertyGridWnd * pGrid = arrGrids[ nGridIdx ];
        ASSERT_VALID( pGrid );
        HTREEITEM hTreeItem = pGrid->PropertyItemToTreeItem( pPropertyValue );
        if( hTreeItem == NULL )
            continue;
        CExtGridCell * pGridCell = pGrid->ItemGetCell( hTreeItem, 1 );
        if( pGridCell == NULL )
            continue;
        ASSERT_VALID( pGridCell );
        pGridCell->Assign( pValueBool );
        if( (pGrid->GetStyle()&WS_VISIBLE) == 0 )
            continue;
        LONG nRowNo = pGrid->ItemGetVisibleIndexOf( hTreeItem );
        if( nRowNo < 0 )
            continue;
        CRect rc;
        if( pGrid->GridCellRectsGet( 1, nRowNo, 0, 0, NULL, &rc ) )
        {
            CRect rcClient;
            pGrid->GetClientRect( &rcClient );
            rc.left = rcClient.left;
            rc.right = rcClient.right;
            pGrid->InvalidateRect( &rc );
        }
    }

As a result, you should not loose focus/selection nor scroll position in any of the tree grid windows inside the property grid control.

In my case also.. when I change the value of one row.. then some of the specific rows should have updated values.. In that case I was calling CExtPropertyGridCtrl::PropertyStoreSynchronize()


can I also use the code....

Dear Support,

Again I’m having problem with your FormEditor sample. What I’m trying to achieve is that controls placed onto a groupbox shall be visible at all times. When testing around this issue, I saw a strange behaviour of your original sample: no matter how many controls I try to create, last created control is always drawn "under" groupbox, all others are drawn above it (as I’d like all of them to be). Could you please check this issue?

Thank you,
Chris

Please update the source code for the CFormEditorView::SyncDocItems() method in the FormEditor sample to fix the Z-order issue:

void CFormEditorView::SyncDocItems()
{
    ASSERT_VALID( this );
CFormEditorDoc* pDoc = GetDocument();
    ASSERT_VALID(pDoc);
    SetRedraw( FALSE );
 
    m_mapSelection.RemoveAll();
 
HWND hWndChild = ::GetWindow( m_hWnd, GW_CHILD );
    for( ;    hWndChild != NULL;
            hWndChild = ::GetWindow( m_hWnd, GW_CHILD )
            )
        ::DestroyWindow( hWndChild );
 
CClientDC dc( this );
    OnPrepareDC( &dc, NULL );
 
    for( int nItem = 0; nItem < pDoc->m_vItems.GetSize(); nItem++ )
    {
        CFormEditorDoc::DOC_ITEM_DATA & _did =
            pDoc->m_vItems[ nItem ];
        CString sClassName;
        VERIFY(
            CFormEditorToolBoxWnd::g_mapIdToWndClassName.Lookup(
                _did.m_dwItemID,
                sClassName
                )
            );
        ASSERT( !sClassName.IsEmpty() );
        DWORD dwAdditionalWindowStyles = 0L;
        VERIFY(
            CFormEditorToolBoxWnd::g_mapIdToWndStyle.Lookup(
                _did.m_dwItemID,
                dwAdditionalWindowStyles
                )
            );
        CRect rcItem( _did.m_rcItem );
        dc.LPtoDP( &rcItem );
        hWndChild =
            ::CreateWindowEx(
                WS_EX_TRANSPARENT,
                _T("STATIC"),
                NULL,
                WS_CHILD|WS_VISIBLE|WS_CLIPSIBLINGS|WS_CLIPCHILDREN,
                rcItem.left,
                rcItem.top,
                rcItem.Width(),
                rcItem.Height(),
                m_hWnd,
                (HMENU)NULL,
                ::AfxGetInstanceHandle(),
                0L
                );
        ASSERT( hWndChild != NULL );
        ::EnableWindow( hWndChild, FALSE );
        HWND hWndControl =
            ::CreateWindowEx(
                WS_EX_TRANSPARENT,
                (LPCTSTR)sClassName,
                NULL,
                WS_CHILD|WS_VISIBLE|WS_CLIPSIBLINGS|WS_CLIPCHILDREN
                    |dwAdditionalWindowStyles,
                0,
                0,
                _did.m_rcItem.Width(),
                _did.m_rcItem.Height(),
                hWndChild,
                (HMENU)NULL,
                ::AfxGetInstanceHandle(),
                0L
                );
        ASSERT( hWndControl != NULL );
        hWndControl;
        //////////////////////////////////////////////
        //////////////////////////////////////////////
        //////////////////////////////////////////////
        //
        // ADDED:
        //
        ::SetWindowPos(
            hWndChild, HWND_TOP, 0, 0, 0, 0,
            SWP_NOMOVE|SWP_NOSIZE
            );
        //////////////////////////////////////////////
        //////////////////////////////////////////////
        //////////////////////////////////////////////
    }
    SetRedraw( TRUE );
    RedrawWindow(
        NULL,
        NULL,
        RDW_INVALIDATE|RDW_ERASE
            |RDW_UPDATENOW|RDW_ERASENOW
            |RDW_ALLCHILDREN
        );
    RedrawRuler( true );
    RedrawRuler( false );
}

Sorry, this won’t be good, it messes up the other functions, which depend on the HWND order being the same as the order in m_vItems. Adding those lines, now when I resize any of the controls, the control types switch.

The z-order based painting you noticed is provided by Windows OS. There is an alternative design of the form editor’s view window. It is based on invisible controls inside the form area. The invisible controls are painted into a bitmap buffer and later are painted to the form area. You can download the updated version of the FormEditor sample from our website.


Please also update the source code for the CExtPaintManager::stat_PrintWnd() method in ..\Prof-UIS\Src\ExtPaintManager.cpp and its declaration in ..\Prof-UIS\Include\ExtPaintManager.h:

HBITMAP CExtPaintManager::stat_PrintWnd(
    HWND hWnd,
    UINT nMessage, // = WM_PRINTCLIENT
    LPARAM lParamPrint, // = PRF_NONCLIENT|PRF_CLIENT|PRF_ERASEBKGND|PRF_CHILDREN
    HDC hSrcDC, // = NULL
    const RECT * pRectFillSrc // = NULL
    )
{
    ASSERT( hWnd != NULL && ::IsWindow(hWnd) );
    ASSERT( nMessage == WM_PRINT || nMessage == WM_PRINTCLIENT );
CRect rcWnd, rcClient;
    ::GetWindowRect( hWnd, &rcWnd );
    ::GetClientRect( hWnd, &rcClient );
CSize _sizeDest =
        ( (lParamPrint&PRF_NONCLIENT) != 0 )
            ? rcWnd.Size()
            : rcClient.Size()
            ;
HDC hDC = ::CreateCompatibleDC( NULL );
    if( hDC == NULL )
    {
        ASSERT( FALSE );
        return NULL;
    }
BITMAPINFOHEADER bih;
    ::memset( &bih, 0, sizeof(BITMAPINFOHEADER) );
    bih.biSize = sizeof(BITMAPINFOHEADER);
    bih.biWidth = _sizeDest.cx;
    bih.biHeight = _sizeDest.cy;
    bih.biPlanes = 1;
    bih.biBitCount = 32;
    bih.biCompression = BI_RGB;
    bih.biSizeImage = _sizeDest.cx * _sizeDest.cy;
COLORREF * pSurface = NULL;
HBITMAP hBmpSufrace =
        ::CreateDIBSection(
            hDC,
            (LPBITMAPINFO)&bih,
            DIB_RGB_COLORS,
            (void **)&pSurface,
            NULL,
            NULL
            );
    ASSERT( hBmpSufrace != NULL );
    if( hBmpSufrace == NULL )
    {
        ::DeleteDC( hDC );
        ASSERT( FALSE );
        return NULL;
    }
    ASSERT( pSurface != NULL );
HGDIOBJ hBmpOld = ::SelectObject( hDC, (HGDIOBJ)hBmpSufrace );
    if(     hSrcDC != NULL
        &&  pRectFillSrc != NULL
        &&  pRectFillSrc->left < pRectFillSrc->right
        &&  pRectFillSrc->top < pRectFillSrc->bottom
        )
        ::BitBlt(
            hDC,
            0,
            0,
            pRectFillSrc->right - pRectFillSrc->left,
            pRectFillSrc->bottom - pRectFillSrc->top,
            hSrcDC,
            pRectFillSrc->left,
            pRectFillSrc->top,
            SRCCOPY
            );
LRESULT lResult =
    ::SendMessage(
        hWnd,
        nMessage,
        (WPARAM)hDC,
        lParamPrint
        );
    if( lResult != 0 )
    {
        COLORREF clrBk = ::GetSysColor( COLOR_WINDOW );
        COLORREF clrBkOld = ::SetBkColor( hDC, clrBk );
        CRect rect( 0, 0, _sizeDest.cx, _sizeDest.cy );
        ::ExtTextOut( hDC, 0, 0, ETO_OPAQUE, &rect, NULL, 0, NULL );
        ::SetBkColor( hDC, clrBkOld );
    }
    ::SelectObject( hDC, (HGDIOBJ)hBmpOld );
    ::DeleteDC( hDC );
    return hBmpSufrace;
}

1. I’ve updated CExtPaintManager::stat_PrintWnd(), rebuilt my lib file and tested the new sample you provided, but some controls were not painted correctly. Could it be that I need the latest of your source code? (I’m using v2.55 now.)

2. Will this CExtPaintManager::stat_PrintWnd() update be available in the next version of Prof-UIS, or will I have to apply this change after upgrading?

3. As I mentioned earlier, I heavily modified your FormEditor sample, so to my application I would like to apply only the neccessary changes from your original FormEditor to this updated version. For this reason I did some code comparing. Could you please check if I missed any of the changes? These are the ones I found:
a) From CFormEditorView::OnDraw you removed a loop with ExcludeClipRect in it, and added a block of code for drawing the controls between the if blocks of "draw selected layout" and "draw tab orders".
b) In CFormEditorView::SyncDocItems you removed WS_VISIBLE style from creation of hWndChild.
c) In CMainFrame::PreCreateWindow you added a line cs.style |= WS_CLIPCHILDREN|WS_CLIPSIBLINGS; .
d) In CFormEditorToolBoxWnd::arrItems you changed some m_sClassName elements to EDIT.

4. I understand why all these changes are needed except for d). Could you explain?

5. In CFormEditorView::OnDraw can I place the block of code for drawing the controls before block "draw selected layout"? That way the selection rectangles could be visible even when controls are partially hidden by each other.

Here are the answers to your questions:

1 and 3d ) The new approach is based on the WM_PRINTCLIENT standard Windows message which is used for printing window surfaces. We were very surprised to discover that not all standard Windows common controls are handling this message. That is why some controls are drawn incorrectly and some of them are replaced with edit controls.

2) It will be available in Prof-UIS as it is in your copy of Prof-UIS now.

3 and 4) 3a and 3b are essential. 3c is not required. 3d is not required if you are using Prof-UIS controls and/or ActiveX controls. Otherwise, please provide additional information about the controls used in your form designer application.

5) Yes, it is reasonable.

I’m using the following controls:
- the ones printing fine: Static, editbox, chechbox, radio button, group box (actually group box prints the border only, but thats fine with me, maybe even better that way)
- the ones I’m having trouble with:
a) combobox (shall I subclass to CExtComboBox?)
b) listbox (prints fine when empty, prints only texts and their backgrounds after inserting some elements into it (no Prof-UIS class to subclass to, maybe I should derive a class of mine and handle WM_PRINTCLIENT myself?)
c) DateTimePicker (right now created as SysDateTimePick32 and then subclassed as CExtDateTimeWnd; doesn’t print background, only text and dropdown-button)
d) Picture control derived from static, I’m using IPicture to draw pictures like .ico, .bmp, .jpg, .gif. I’m still working on that one.

Am I going to the right direction with combobox and listbox? What are your suggestions about DateTimePicker?

Thank you:
Chris.

Switching to CExtComboBox and other Prof-UIS classes should solve the problem because they implement both WM_PRINT and WM_PRINTCLIENT message handlers and paint everything from scratch. The CExtDateTimeWnd class is not based on the date/time picker common control so you have subclassed it incorrectly. The CExtDateTimeWnd class is derived from the CExtDurationWnd class and uses the ProfUIS-DurationWnd window class name that is defined by the __EXT_DURATION_CLASS_NAME preprocessor symbol. You should create the CExtDateTimeWnd window using the MFC apprach -- not Win32’s used in the FormEditor sample. The only solution we can see at the moment for the list box is to replace it with the CExtGridWnd window with a single column being automatically stretched out to fit the entire client area of the grid.

- I’ve subclassed to CExtComboBox, but it’s still painted only as a white rectengle, as if it was an editbox. But when debugging, I can see that your painting code is called (CExtComboBox::_OnDrawComboImpl). I’m guessing it is not drawn on the screen correctly because somewhere in your code it might be checked if the control is visible or not. And since the control is not visible, it is not drawn (printed).

- I’ve switched to use __EXT_DURATIONWND_CLASS_NAME classname instead of SysDateTimePick32. I didn’t really understand what you meant by MFC approach in your last post, but if I call CExtDurationWnd::RegisterWndClass(); before ::CreateWindowEx, it works fine, I can subclass to CExtDateTimeWnd without crash. But nothing is painted on the form where the control should be. I checked this subclassing with the original painting approach (using visible controls and ExcludeClipRect), and I can see the control is subclassed just fine. I did a search for WM_PRINTCLIENT in your source code, but only CExtControlBar and CExtComboBox handles this message. I’m still wondering: do I need higher version of ProfUIS? (I’m using v2.55)

- I’m still deciding if I should go for your suggestion with CExtGridWnd. The problem is, if I want it to act exactly like CListBox, that single column should be stretched not to the client area, but to the longest string in the grid if the longest string is longer than the width of the grid.
I’m working on it.

We tried to find the cause of the Z-order problem in the FormEditor sample. We came to conclusion it is possible to fix the problem using both ways: visible child controls like in the original version of the sample and invisible child controls as we tried to implement for you. The new version of this sample shows both ways and has a new Prof-UIS Controls group inside the toolbox:

FormEditor-Advanced.zip

The following line in the MainFrm.h file is commented by default and the visible controls are used on the form view://#define __FORM_EDITOR_INVISIBLE_MODE__You can uncomment this line to make the FormEditor sample using invisible controls and form painting based on the window printing. We think this mode is not the best, but it is supported.

When the application started, please invoke the Reset ToolBox command from the context menu over toolbox window. This is needed to make the new Prof-UIS Controls group visible. All the Prof-UIS controls are initialized using the MFC window creation way in the CFormEditorView::SyncDocItems() method. We have also changed control moving/resizing code to make it compatible with both form view modes.

Thank you very much for your efforts! I tried the latest version of the sample with my original Prof-UIS (v2.55) but it looked so bad that (although you didn’t mention I needed) I’ve downloaded v2.63 to check it with that, as well. New lib didn’t compile. It had problem with first parameter of _tcsncmp in this code in CExtPaintManager::stat_PrintWnd:

			CRuntimeClass * pRTC = pWnd->GetRuntimeClass();
			ASSERT( pRTC != NULL );
			if( _tcsncmp( pRTC->m_lpszClassName, _T("CExt"), 4 ) == 0 )
			bOverPaint = false;

, so I changed that line to if( strncmp( pRTC->m_lpszClassName, "CExt", 4 ) == 0 ) . I’m not sure if this is good fix for all the configurations, but we are only using Static Unicode Debug and Static Unicode Release configurations and they compiled fine. Please, check this issue.

As for the new FormEditor: Looks great! Since I need the selection rectangles even when over groupbox, I’d go for the invisible mode. But in both modes controls inside a groupbox flicker when moving any other control. And in invisible mode when moving control over a groupbox, it is not visible while still dragging it but not moving the mouse. As soon as I release the mouse button, control is visible as expected. Flickering is not such a big problem, but is there anything we could do about this second issue?

Thank you,
Chris.

Please download the latest code from our ftp site. The new version of the FormEditor sample is based on the "invisible" form editing algorithm by default and moving/resizing code is updated to show correct z-order of controls.

One little thing though, which has nothing to do with previous problems, but it’s in your new FormEditor_Advanced:
When placing a CExtGrid on the form, its scrollbars are not drawn. Actually while resizing the control, I can see the scrollbars drawn, but as soon as I release the mouse button, there are only theme-specific colored rectangles drawn where scrollbars should be.

I have a Main Dialog. i want to put some controls on this main Dialog like Button , MenuBar and ToolBar. And i also want to put Tab Pages on
this Main Dialog. All the Tab Pages are different Dialogs. I m doing Different Tasks on Different Dialog. I Also Want to Put Dynamic Context Menu ( Dont want to create the context manu in resource) on Dialogs.
One Button Of main Dailog is Exactly Similar to "Views" Button of windows. which gives option like " Large View " Small View" Details" etc.



Can u provide Me a Sample Project wich supports all these fetures. Please this is urgent . and help me as quick as u can

thanks in advance

I modified ProfUIS_Controls sample to fit your needs. The Dynamic context menu is implemented in the OnContextMenu method of CPageBase class.

This sentence wasn’t really clear:
"One Button Of main Dailog is Exactly Similar to "Views" Button of windows. which gives option like " Large View " Small View" Details" etc."
Large View, Details, etc makes only sense when working with CListView. Do you need a button with a dropdown menu appearing when pressing it? If so, it is shown in the CPageButtons class.

You can download the modified sample from here. I tested it with Static Unicode Debug configuration with ProfUIS v2.55.

yeah my main concern is button with drop down menu.Main dialog with different tab pages. all tab pages are different dialog. i also want to add some controls like tool bar , menu bar , buttons on the main dialog. The link u have provided me "here" for downloading the sample is not working . so please check it.

Hello,

How do you put a kind of wave in the background of you frame window ?

Thanks.

Hi,

I have a property grid with cells called CCheckComboProperty that contains a cell of type CExtGridCellCheckListComboBox.

This is what I do in the cell’s c’tor:

CExtGridCellCheckListComboBox* pCell = STATIC_DOWNCAST(CExtGridCellCheckListComboBox, ValueActiveGetByRTC(RUNTIME_CLASS(CExtGridCellCheckListComboBox)));

I have added a function called AddItem:

bool CCheckComboProperty::AddItem(CString strName, int nItemData)
{
    CExtGridCellCheckListComboBox* pCell = (CExtGridCellCheckListComboBox*)ValueActiveGet();
    pCell->AddString(strName, nItemData);
    return true;
}

And it is called several items.

The problem is that nothing happens - the list is not filled.

What am i missing?

Please note that if I call AddString on the cell i got in the c’tor it works.
Do I need to call any other function in order for my changes to be displayed in the cell?

Thanks,
Ron.

Any CExtPropertyValue object contains two CExtGridCell grid cell objects: the default value and the current value. These are the ones you get when calling ValueDefaultGet and ValueActiveGet. But there’s a third cell that has to be taken in consideration in this case: The cell that is displayed in the currently active CExtPropertyGridWnd. When user changes something in this last cell, PropertyGrid calls Apply, which in turn should assign the value in this cell to the CExtPropertyValue’s active cell.

So main thing: When you call AddItem from somewhere outside the constructor, you adding items only to the CExtPropertyValue’s active cell, not to the cell displayed in the grid. It works in the contructor fine because the displayed cell gets initialized from the CExtPropertyValue’s active cell after the constructor was called. If you change the PropertyStore in any way and you want to display this changed one in the grid, you have to call PropertyStoreSynchronize method. This messes with your CExtPropertyGridTipBar, so if you have that displayed, you better call it like this:

			CExtPropertyGridCtrl * pPGC = ...;
			pPGC->SetRedraw( FALSE );
			pPGC->PropertyStoreSynchronize();
			pPGC->SetRedraw( TRUE );
			pPGC->RedrawWindow( NULL, NULL, RDW_INVALIDATE|RDW_ERASE|RDW_ALLCHILDREN );

Thanks!
Now it’s all clear (and works...)

Question - how do you format your posts like the support does?

I’m using HTML tags: <pre><code>my code</code></pre>

Thanks...

Dear Support,

I would like to return and iterate that this does not work for the CExtGridCellCheckListComboBox type cell when changing the check status, event if I call PropertyStoreSynchronize, the content of the displayed cell does not change, and the drop list does not show the new checked items.

Please fix.
Thanks,
Ron.

It seems we found what the problem was caused by. Please find the CExtGridCellComboBox declaration and update these two ITEM_INFO constructors:

ITEM_INFO(
    __EXT_MFC_SAFE_LPCTSTR lpszString,
    DWORD dwItemData = 0,
    INT nImage = -1,
    INT nSelectedImage = -1,
    INT nOverlayImage = -1,
    INT nIndent = 0,
    INT nCheck = 0
    )
    : m_sString( lpszString )
    , m_dwItemData( dwItemData )
    , m_nImage( nImage )
    , m_nSelectedImage( nSelectedImage )
    , m_nOverlayImage( nOverlayImage )
    , m_nIndent( nIndent )
    , m_nCheck( nCheck )
{
}
ITEM_INFO( const ITEM_INFO & other )
    : m_sString( other.m_sString )
    , m_dwItemData( other.m_dwItemData )
    , m_nImage( other.m_nImage )
    , m_nSelectedImage( other.m_nSelectedImage )
    , m_nOverlayImage( other.m_nOverlayImage )
    , m_nIndent( other.m_nIndent )
    , m_nCheck( other.m_nCheck )
{
}

This does not solve the problem!
Please check it again.