Forum

Hi,

in my application I used a CDialogBar derived class to provide some complex gui elemtents in a sort-of tool bar. This dialog bar is part of CCmdUI / ON_UPDATE_CMD_UI handling (like normal menues).

When I installed CExtButton (instead of CButton) in this CDialogBar class, every inactive button gets permanently redrawn due to frequent OnIdleUpdateCommandUI calls (MFC). If the button is enabled, everything works well. With only 2 inaktive buttons I measure 30% CPU load only with redrawing (which makes a permanent flicker of this button on screen).

I could reproduce the problem with a simple SDI Application from scratch (since my application is confusingly complex and possibly having other pitfalls). I can mail you the whole testing application, here the changes I made from an MFC Wizzard code.

Did I miss anything essential?

Thanks,

Peter.



CTextApp::InitInstance:
...
    if( ! g_PaintManager.PaintManagerStateLoad(
            pApp->m_pszRegistryKey,
            pApp->m_pszProfileName,
            pApp->m_pszProfileName))
    {
        g_PaintManager.InstallPaintManager(
            RUNTIME_CLASS(CExtPaintManagerOffice2007_R2_LunaBlue));
    }

Create a simple dialog bar:
    IDD_DIALOGBAR DIALOGEX 0, 0, 408, 28
    STYLE DS_SETFONT | DS_FIXEDSYS | WS_CHILD | WS_SYSMENU
    FONT 8, "MS Shell Dlg", 400, 0, 0x1
    BEGIN
     DEFPUSHBUTTON "Test2",IDD_TEST2,123,7,50,14
     PUSHBUTTON "Test1",IDD_TEST1,56,7,50,14
    END

Write a handler class "CMyDialogBar":
    class CMyDialogBar : public CDialogBar
    {
    public:
        CMyDialogBar() {};
    
        CExtButton    m_btButton1;
        CExtButton    m_btButton2;

    protected:
        virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
    };

    void CMyDialogBar::DoDataExchange(CDataExchange* pDX)
    {
        CDialogBar::DoDataExchange(pDX);
        //{{AFX_DATA_MAP(CButtonBar)
        DDX_Control(pDX, IDD_TEST1, m_btButton1);
        DDX_Control(pDX, IDD_TEST2, m_btButton2);
    }

In CMainFrame add:
...
CMyDialogBar    m_wndButtonBar;

In CMainFrame add msg handler (leave second button unattached for testing):

    ON_BN_CLICKED(IDD_TEST1, OnTest1)

In CMainFrame::OnCreate add new dialogbar:
    ...
    if (!m_wndButtonBar.Create(this, IDD_DIALOGBAR, CBRS_TOP,
                AFX_IDW_CONTROLBAR_FIRST))
    {
        TRACE0("Failed to create dialog bar.\n");
        return -1; // fail to create
    }
...
    m_wndButtonBar.EnableDocking(CBRS_ALIGN_ANY);
    ...
    DockControlBar(&m_wndButtonBar);
    ...
    m_wndButtonBar.UpdateData(FALSE);    // to simplify control attachment.

That’s it, the inactive button will flicker (visible best when you hover with the mouse over it) and make the CPU glow. :-)

After further testing it seems to me that every call to

pCmdUI->Enable(...);
or
pCmdUI->SetCheck(...);

in an OnUpdateCmdUI handler causes a visible CExt-Control to be redrawn, without considering it’s current state (if redraw is needed or not).

Tnx,
Peter.

Dear Support,

I would like to add a check-box in a section header row, that when checked, all items in the section are enabled, and vice-versa.
Is it possible? If not, any suggestion of how to achieve this behavior?

Thanks,
Ron.

I think so too (that’s why I asked for it in the first place)

Some things to improve
(i) Better support for having check boxes on only some items.
(ii) Make sure it works well when in a mixed property (when combining property stores) - maybe uses thrid check state if the children of the mixed property have different values - i.e. one disabled and the other enabled.
(iii) Have "strong" parent/child behaviour (applicable to categorized view only), where ticking the category enabled or disables all its children, where the children don’t necessarily need to have a check box. If a child does have a check box then ticking/ unticking the parents one doesn’t tick the childs one. In this case the child is only enabled if its check box is enabeld and the parents one is enabled too.


Thanks

The check boxes can be displayed or hidden in each tree grid window in the property grid control and independently of property categories (m_bInputEnabledCheckMarksInCategories) and property values(m_bInputEnabledCheckMarksInValues):

CExtPropertyGridCtrl * pPGC = . . .
      ASSERT_VALID( pPGC );
CTypedPtrArray < CPtrArray, CExtPropertyGridWnd * > arrGrids;
      pPGC->OnPgcQueryGrids( arrGrids );
INT nGridIdx = 0;
      for( ; nGridIdx < arrGrids.GetSize(); nGridIdx ++ )
      {
            CExtPropertyGridWnd * pPGW = arrGrids[ nGridIdx ];
            ASSERT_VALID( pPGW );
            pPGW ->m_bInputEnabledCheckMarksInCategories = true; // or false
            pPGW ->m_bInputEnabledCheckMarksInValues = true; // or false
            pPGW ->m_bInputEnabledNestedFlags = true; // or false
      }

The m_bInputEnabledNestedFlags flag turns on/off the nested dependency on the "input enabled" check marks in the property tree.

Because I don’t have direct access to the cells, hod do I:
1. Get an event/virtual function to override when a cetegory check state have changed.
2. Get the check state of a check-box of a specific category.
3. Set the check state of a check-box of a specific category.

Thanks,
Ron.

Here are these methods:

1) The CExtPropertyGridCtrl::OnPgcPropertyInputEnabled() and CExtPropertyItem::OnInputEnabledSet() virtual methods.
2) The CExtPropertyItem::InputEnabledGet()method.
3) The CExtPropertyItem::InputEnabledSet() method.

Thanks.

I need the check-box in a specific category, and not in all of them.
The flag you specified is one that adds a check-box to all categories.

You can achieve this by overriding the CExtPropertyGridWnd::_OnSynchronizeInputEnabledCheckMark() internal virtual method in both the CExtPropertyGridWndCategorized and CExtPropertyGridWndSorted classes. The method defines the "input enabled" check boxes in grid cells. Here is the default implementation which you can modify in order to insert per-item check boxes:

void CExtPropertyGridWnd::_OnSynchronizeInputEnabledCheckMark(
      CExtPropertyItem * pPropertyItem,
      bool bSychronizeChildren // = true
      )
{
      ASSERT_VALID( this );
      ASSERT_VALID( pPropertyItem );
HTREEITEM hTreeItem = PropertyItemToTreeItem( pPropertyItem );
      if( hTreeItem != NULL )
      {
            CExtGridCell * pCellCaption = ItemGetCell( hTreeItem, 0L );
            ASSERT_VALID( pCellCaption );
            pCellCaption->ModifyStyle( 0, __EGCS_CHK_MASK );
            if( m_bInputEnabledCheckMarksInCategories && pPropertyItem->IsKindOf( RUNTIME_CLASS(CExtPropertyCategory) ) )
            {
                  pCellCaption->ModifyStyle( __EGCS_CHK_CHECK );
                  if( pPropertyItem->OnInputEnabledGet( false ) )
                        pCellCaption->ModifyStyle( __EGCS_CHECKED );
                  else
                        pCellCaption->ModifyStyle( 0, __EGCS_CHECKED );
            } // if( m_bInputEnabledCheckMarksInCategories && pPropertyItem->IsKindOf( RUNTIME_CLASS(CExtPropertyCategory) ) )
            CExtGridCell * pCellValue = ItemGetCell( hTreeItem, 1L );
            if( pCellValue != NULL )
            {
                  ASSERT_VALID( pCellValue );
                  if( m_bInputEnabledCheckMarksInValues && pPropertyItem->IsKindOf( RUNTIME_CLASS(CExtPropertyValue) ) )
                  {
                        pCellCaption->ModifyStyle( __EGCS_CHK_CHECK );
                        if( pPropertyItem->OnInputEnabledGet( false ) )
                        {
                              pCellCaption->ModifyStyle( __EGCS_CHECKED, 0 );
                              pCellValue->ModifyStyle( 0, __EGCS_READ_ONLY|__EGCS_NO_INPLACE_CONTROL );
                        } // if( pPropertyItem->OnInputEnabledGet( false ) )
                        else
                        {
                              pCellCaption->ModifyStyle( 0, __EGCS_CHECKED );
                              pCellValue->ModifyStyle( __EGCS_READ_ONLY|__EGCS_NO_INPLACE_CONTROL, 0 );
                        } // else from if( pPropertyItem->OnInputEnabledGet( false ) )
                  } // if( m_bInputEnabledCheckMarksInValues && pPropertyItem->IsKindOf( RUNTIME_CLASS(CExtPropertyValue) ) )
            } // if( pCellValue != NULL )
      } // if( hTreeItem != NULL )
      if( bSychronizeChildren )
      {
            INT nIndex, nCount = pPropertyItem->ItemGetCount();
            for( nIndex = 0; nIndex < nCount; nIndex++ )
            {
                  CExtPropertyItem * pItem = pPropertyItem->ItemGetAt( nIndex );
                  ASSERT_VALID( pItem );
                  _OnSynchronizeInputEnabledCheckMark( pItem, true );
            } // for( nIndex = 0; nIndex < nCount; nIndex++ )
      } // if( bSychronizeChildren )
}

Here is the CExtPropertyGridCtrl::OnPgcCreateGrids() virtual method in which you can instantiate your custom tree grid classes (instead of those created by default):

bool CExtPropertyGridCtrl::OnPgcCreateGrids()
{
      ASSERT_VALID( this );
      try
      {
            CExtPropertyGridWndCategorized * pGridCategorized =
                  new CExtPropertyGridWndCategorized( this );
            pGridCategorized->m_bAutoDeleteWindow = true;
            if( ! pGridCategorized->Create(
                        this,
                        __EXT_MFC_ID_PROPERTY_GRID_CATEGORIZED,
                        true
                        )
                  )
            {
                  ASSERT( FALSE );
                  throw __EXT_MFC_ID_PROPERTY_GRID_CATEGORIZED;
            }
            CExtPropertyGridWndSorted * pGridSorted =
                  new CExtPropertyGridWndSorted( this );
            pGridSorted->m_bAutoDeleteWindow = true;
            if( ! pGridSorted->Create(
                        this,
                        __EXT_MFC_ID_PROPERTY_GRID_SORTED
                        )
                  )
            {
                  ASSERT( FALSE );
                  throw __EXT_MFC_ID_PROPERTY_GRID_SORTED;
            }
      }
      catch( ... )
      {
            return false;
      }
      return true;
}

Is there sample code for customizing CExtGridWnd inplace controls? We want an in-place progress bar.

I loaded and built the ProfUIS_Controls sample, but I could find no Grid tab in the running app. A check of the source code confirms that not only is CExtGridCellProgress not being used by the ProfUIS_Controls sample, but there is no CExtGridWnd in the sample at all.

Nevertheless, I tried making a Grid Cell into a CExtGridCellProgress by the usual method:

CExtGridCellProgress *pCellProgress =
STATIC_DOWNCAST(
CExtGridCellProgress,
m_wndGrid.GridCellGet(
nColNo,
nRowNo,
0,
0,
RUNTIME_CLASS(CExtGridCellProgress)
)
);

... and this code ended up causing an Assertion failure in MFC code that implements the STATIC_DOWNCAST macro -- the Grid Cell object being returned wasn’t even of type CExtGridCellProgress !

We appear to be using Prof-UIS version 2.5.3.0, if that makes any difference.

Please take a look at the ProfUIS_Controls sample carefully. In the CPageGrid class there is a variable m_wndGrid, which represents a grid with class name CMyGridWnd. The progress cells are initialized in the CPageGrid::_InitColumnProgress() method.

The STATIC_DOWNCAST macro ASSERTs if the cell object returned by the GridCellGet method does not point to an object derived directly or indirectly from CExtGridCellProgress. In other words, the cell with coordinates specified by nColNo and nRowNo is already instantiated and has another type, not CExtGridCellProgress.

Hi,

our application uses the ansi charset in all its project appart 1.

This projects uses mbcs as charset. Therefore it tries to link to ProfUIS270md.dll.

Is-it possible to force the use of ProfUIS270nd.dll for that specific project ?

It’s possible if you replace the following line in the ../Prof-UIS/Include/ExtMfcDef.h file:

                              #define __PROF_UIS_LIB_NAME            "ProfUIS270md.lib"

with the following one:

                              #define __PROF_UIS_LIB_NAME            "ProfUIS270nd.lib"

Hi,

I’m using a CExtTabMdiWhidbeyWnd to host my frame/doc/view.

When I create the doc/view I have a default name, Aname1 (for example), this name gets displayed in the tab.

Then I change the name to something that fits our need, for example A_Name_That_Makes_Sense.

My issue is that the tab keeps the old name and it doesn’t resize automaticaly.

The tab is aware of the new name, when mouse passes on it the correct name gets displayed.

The tab is also aware of the size it should use because when I click on it, its size is adapted.

How can I display the correct name and size automaticaly ?

Hi,

I found the problem. I have overridden CExtTabMdiWhidbeyWnd::OnTabWndQueryItemText() and the code is not appropriate. The call to UpdateTabWnd() is perfect.

The CExtTabMdiWhidbeyWnd is a member of our MainFrame, m_wndMdiTabs.

In the MainFrame we added a method such as

void OurMainFrame::UpdateTabWnd()
{
    m_wndMdiTabs.UpdateTabWnd();
}

after creating the View we call

((OurMainFrame*)AfxGetApp()->m_pMainWnd)->UpdateTabWnd();

and it works

Hope it can help you.

Hi,
I have same problem. I create CExtDynamicControlBar to put views and the CExtTabMdiWhidbeyWnd automatically update with a new tab but the caption is not there. When the mouse come on the tab, the text appear but no sizing occur. When I click the tab the refresh is made and all is OK.

I have tried the CExtTabMdiWhidbeyWnd::UpdateTabWnd() with no effect. When I search for the new TAB_ITEM_INFO added I don’t find him. How can I corrected this problem?

Thank you!

I think all you need is to call CExtTabMdiWhidbeyWnd::UpdateTabWnd();

Dear Support,

I’m trying to implement the kind of feature which I’ve seen in some applications using Toolbox: When the user doubleclicks a Toolbox item, it gets "locked", and that item stays selected even after creating an object of the type represented by the Toolbox item. I have some questions regarding this.

1. In my CExtToolBoxWnd-derived class I handle the WM_LBUTTONDBLCLK message. It works fine mostly, but if my Toolbox item is too long and ContentExpand window is needed to see the full title of the item, WM_LBUTTONDBLCLK stops working, I guess because ContentExpand window receives the click instead of the Toolbox window. How could I resolve this?

2. While reading through your code regarding doubleclick in Toolbox, I’ve seen that the original CExtToolBoxWnd class handles the WM_LBUTTONDBLCLK message as well, it seems for editing the items. I’ve tried to make a sample demonstrating this doubleclick problem, but I couldn’t get the item to go into editor mode, not even the ones without ContentExpand window. I’ve applied the __TBWI_EDITABLE style to all items and OnToolBoxWndStartItemEditor returns a valid HWND in CExtToolBoxWnd::OnLButtonDblClk, but still the inplace editor does not appear. Why?

Best regards,
Chris

Please find the following code in the CExtToolBoxWnd::OnToolBoxWndItemHoverChange() method:

      m_wndContentExpand.Activate(
            rcItem,
            this,
            __ECWAF_DEFAULT|__ECWAF_DRAW_SOURCE
            );

and replace it with:

      m_wndContentExpand.Activate(
            rcItem,
            this,
            __ECWAF_DEFAULT|__ECWAF_DRAW_SOURCE|__ECWAF_TRANSPARENT_WND
            );

Now the popup window has the WS_EX_TRANSPARENT extended window style and passes the mouse clicks through it.

To fix the editing issues, use the following two changes:

1) The CExtToolBoxWnd::OnLButtonDown() method should have the following code at the beginning:

      if( m_hWndEditor != NULL )
      {
            CPoint ptScreen = point;
            ClientToScreen( &ptScreen );
            if( ::WindowFromPoint( ptScreen ) == m_hWndEditor )
                  return;
      }

2) The CExtToolBoxWnd::OnLButtonUp() and CExtToolBoxWnd::OnMouseMove() methods should have the following code at the beginning:

      if( GetEditorHWND() != NULL )
            return;

I’m sorry, I should have written only after trying to see if the fix worked. But unfortunately it doesn’t. In my app I only need the proper responding to doubleclick, so that’s what I tried out. I still don’t receive the message and now the contentexpand window doesn’t paint correctly:
http://people.inf.elte.hu/puffy/Prof-UIS/ProfUIS_ToolBox.jpg

We have just sent you the updated source code for CExtToolBoxWnd. Firstl, please check your application again. If the problem persists, then invoke the Configure Toolbox command from the context menu over the toolbox in the FormEditor sample and try to find a set of toolbox options when the same problem with the expand tip windows appears. If this experiment reproduces the problem, then please send us a screenshot with the toolbox configuration dialog demonstrating checked/unchecked check boxes in it.

First of all: I’m still using v2.64, I don’t know if this could cause the problem. Second: I’m only testing the doubleclick problem, not the one with the inplace editor.

The source code you sent me by e-mail had the __ECWAF_TRANSPARENT_WND flag uncommented in the code of your first post. When the flag is in effect, the strange painting appears. When the flag is not in effect (as in the code you sent me by e-mail), the painting is fine. In either case, I do not receive WM_LBUTTONDBLCLK message. I’ve done my testing with your original FormEditor sample (present in v2.64), adding a very little code in MainFrm.h:

	CExtToolBoxWnd::TOOLBOX_ITEM_DATA * m_pTBCI_helper_menu_focus;
//vv added from here
protected:
	afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point);
	DECLARE_MESSAGE_MAP()
//ˆˆadded till here
private:
	bool	m_bDropBefore:1,

and in MainFrm.cpp:

	{ _T("Custom Control"), __IMG_TOOLBOX_CUSTOMCTRL , false , false, NULL, 0L },

};

//vv added from here
BEGIN_MESSAGE_MAP(CFormEditorToolBoxWnd, CExtToolBoxWnd)
	ON_WM_LBUTTONDBLCLK()
END_MESSAGE_MAP()

void CFormEditorToolBoxWnd::OnLButtonDblClk(UINT nFlags, CPoint point) 
{
	CExtToolBoxWnd::OnLButtonDblClk(nFlags, point);
	CExtToolBoxWnd::TOOLBOX_ITEM_DATA * pTBCI = ItemHitTest( point );
	if ( pTBCI != NULL )
		TRACE1("OnLButtonDblClk %s\n", OnToolBoxWndQueryItemText(pTBCI));
	else
		TRACE0("OnLButtonDblClk Empty\n");
}
//ˆˆ added till here

void CFormEditorToolBoxWnd::_InitToolBoxImpl()
{

Trace message is always seen when doubleclicking an item without ContentExpandWnd, but never seen when doubleclicking an item with long text (where ContentExpandWnd is used).

I tried setting different styles with the toolbox configuration dialog, but the behaviour was the same no matter what toolbox options I chose.

Thank you very much for your help!

The __ECWAF_TRANSPARENT_WND flag makes the content expand window having the WS_EX_TRANSPARENT extended window style which makes window "transparent" for mouse click events. The __ECWAF_TRANSPARENT_WND flag is needed and it can not affect to the Z-Order of the window. We need additional information: which layout should toolbox window use and could you provide us with exact styles of it The problem is not related to the difference in CExtContentExpandWnd and CExtToolBoxWnd classes in 2.64 and 2.70 because they are mostly exactly the same. Would you send us your copy of the FormEditor sample where the problem occurs.

Sample sent. I’m using the default layout of the ToolBox, meaning that I’ve cleared the registry from the saved settings of the sample and reproduced the error right after starting the application. I’d like to clarify: as I stated in my last post and in my e-mail, the version of ExtToolBoxWnd that you’ve sent me yesterday, has the __ECWAF_TRANSPARENT_WND flag commented, even though now you are saying it’s needed!!!

We received your e-mail and replied with a working application ZIPped in attachment.

Reply sent with ZIPped attachment, I hope it went through alright.

We have just replied by email.

Just to clarify and be sure: the very beginning of CExtToolBoxWnd::OnLButtonDown originally looked like this:

void CExtToolBoxWnd::OnLButtonDown(UINT nFlags, CPoint point) 
{
//	CExtScrollWnd::OnLButtonDown(nFlags, point);
	nFlags;
 
	if( GetFocus() != this )
		_SetToolBoxFocus();
 
	if( m_hWndEditor != NULL )
	{
		OnToolBoxWndCancelItemEditor( m_hWndEditor );
		m_hWndEditor = NULL;
	}
	...
}

and now it should look like this:

void CExtToolBoxWnd::OnLButtonDown(UINT nFlags, CPoint point) 
{
//	CExtScrollWnd::OnLButtonDown(nFlags, point);
	nFlags;
 
	if( GetFocus() != this )
		_SetToolBoxFocus();
 
	if( m_hWndEditor != NULL )
	{
		CPoint ptScreen = point;
		ClientToScreen( &ptScreen );
		if( ::WindowFromPoint( ptScreen ) == m_hWndEditor )
			return;
	}
	...
}

Or maybe like this?:

void CExtToolBoxWnd::OnLButtonDown(UINT nFlags, CPoint point) 
{
//	CExtScrollWnd::OnLButtonDown(nFlags, point);
	nFlags;
 
	if( GetFocus() != this )
		_SetToolBoxFocus();
 
	if( m_hWndEditor != NULL )
	{
		CPoint ptScreen = point;
		ClientToScreen( &ptScreen );
		if( ::WindowFromPoint( ptScreen ) == m_hWndEditor )
			return;
		OnToolBoxWndCancelItemEditor( m_hWndEditor );
		m_hWndEditor = NULL;
	}
	...
}

How can I get a border around a grid in a dialog? I’ve tried using WS_BORDER, but it does work in a dialog.

Hello,

I am using CExtPaintManagerOffice2007_R2_LunaBlue theme and need to place an icon on top of the multi-lined text of the CExtButton. Since the button has to be tall, the icon left or right of the text is not applicable (insufficient space).

Can you give me a hint how I can place the Icon above the text ?

Thanks,

Peter.

We implemented this feature a couple of days ago. So you can wait until the next minor release or download the updated source code via ftp.

Dear Support,

I had a post in January with the same title. I’d like to know if the problem was fixed in the new v2.70.

Thank you!
Chris

I am using the horizontal and vertical pixel scrolling style in CExtReportGridWnd.
I’ve noticed a bug.
I you do a grouping and try to select a node, you can only do it if the nouse pointer is in the far left column.
The node won’t be selected if the mouse pointer is in another column.
This seems to happen when the __ESIS_STV_PIXEL style is set.
This is what I’m using:

    SiwModifyStyle(
        __EGBS_RESIZING_CELLS_INNER_H|
        __EGBS_GRIDLINES|
        __EGBS_SFB_CELLS|
        __ESIS_STV_PIXEL|
        __ESIS_STH_PIXEL,
        __EGBS_SFB_MASK|
        __ESIS_STV_MASK|
        __ESIS_STH_MASK,
        false);

I was hoping to bypass a bug using the pixel scrolling ... oh well.
My problem is that the item scrolling (__ESIS_STV_ITEM) has a very strange behaviour when rows are set to height zero.
It’s like the scroll bar still "sees" the hidden rows.
The scroll bar keeps changing it’s size when you scroll up or down.
And sometimes you cannot scroll all the way down to the bottom of the grid.
Now, if all the rows (CExtReportGridItem) are set back to visible (i.e. ExtendSet(22, 0) and ExtendSet(22, 1)) the scroll bar works the way it should.
That’s why I am asking if or when you’ll will have the ReportRowActivate function (same as ReportColumnActivate but for rows).
Or maybe you can tell me what functions I can override to fix this scrolling problem?
Thanks.

Hi,

I just added a CExtTabPageContainerWnd into a docked CExtControlBar.

I’d like to hide the < > navigation button. How can I do this ?

Regards

Pierre

Hello
I’m using the CExtReportGrid and have implemented a row filtering system.
I am setting the row size to zero to hide the rows that don’t match the filter critiria.
At least that’s the quick and easy way to do it.
However it’s prooving to be a little problematic because the grid still "sees" these hidden rows.
i.e. scrolling problems and grouping problems.
Anyway, long story short, do you think the you’ll have the ReportRowActivate function anytime soon?
Thanks

Hi,
Where do I find the code that sets the border and caption sizes for your themed dialogs?

Thanks

Hi

when I double click on a docked toolbar, it gets floating.

How can I get the floating toolbar docked at its previous location. If it is not possible, how can I prevent the docked toolbar to get floating ?

I want to replace ModifyMenu and GetMenuState of CMenu with that of CExtPopupMenuWnd members.
Are they available? If not, pls suggest some workaround for it.

Thanks

I have a code CMenu tempCmenu;
tempCmenu.CreatePopupMenu();
tempMenu.AppendMenu(). //Append various menus depending on conditions...
popupMenu.TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON,
point.x, point.y, this);

Now, I m using CExtPopupMenuWnd tempMenu;
tempMenu.CreatePopupMenu(AfxGetApp()->GetMainWnd()->m_hWnd);
tempMenu.ItemInsertCommand();
popupMenu.TrackPopupMenu(0, point.x, point.y);

By using this, When I run the application, the application stops responding.
I cant use LoadMenu() since the menus are created on the fly.

Is this the correct way?

Also, I m not using any Prof UI rregisterd messages like OnExtMenuPrepareLevel etc.

Hi

I’m currently integrating prof-ui into a MFC application. I created two objects derived from CExtControlBar and I dock them in my MainFrame.

class WorkSpaceWnd : public CExtControlBar
{}

if (!m_wndWorkSpace.Create("Workspace", this, ID_PROF_UI_TREE))
{
    TRACE("Failed to create workspace bar");
    return -1;
}
m_wndWorkSpace.EnableDocking(CBRS_ALIGN_ANY);
m_wndWorkSpace.DockControlBar(AFX_IDW_DOCKBAR_LEFT, 1, this, true);

I’m facing an assert when I press the autohide button.

ASSERT( ((CExtDockBar*)pWndParent)->_GetCircleNo() > 0 );

the _GetCircleN0() returns 0 (it is the value in m_nCircleNo)

What did I do wrong ?

The CExtControlBar::DockControlBar() method is obsolete and supported for compatibility with old versions of Prof-UIS. Please use the CExtControlBar::DockControlBarInnerOuter() and CExtControlBar::DockControlBarLTRB() methods instead. These two methods are designed for docking control bars like in Visual Studio 2005.

I replaced the DockControlBar() with the DockControlInnerOuter() -> I still get the assert.

Could you describe what I should do, I mean what method and the order I should to avoid this assert.


NB : One suggestion, update the content of the help file where you still suggest to use the DockControlBar() method.

Our application uses the LoadBarState() of the CFrameWnd -> can this cause these asserts ?

Dear Support,

I have a Categorized Property Grid, and I see that the categories are sorted by default.
I would like the categories to be in the order i insert them into the grid.

Please Advise.

Regards,
Ron.

You can achieve this using the following approach:

1) Use the following code before assigning a property store to the property grid control:

CExtPropertyGridCtrl * pPGC = . . .
CExtPropertyGridWnd * pPGW =
    STATIC_DOWNCAST( CExtPropertyGridWnd,
        pPGC->GetChildByRTC( RUNTIME_CLASS( CExtPropertyGridWndCategorized ) ) );
    pPGW->m_bSortedCategories = false;

2) Insert your property values and property categories into each sublevel of the property tree using the same order which you want to see on the screen. The previous step turns off any sorting in the property grid.

Hello - I’m new to the library and during my testing and experimenting, I’ve discovered that most of the samples are very slow to resize the internal windows/controls when the main frame window is resized. For instance, if I run the ProfStudio application and drag the main frame window from the lower right corner as the window increases in size I see a large black background that is the difference between the main frame and docking windows or toolbars that should fill that space. Note, I’m resizing the windows very quickly. This sample in particular seems to show the gap the most.

I tried some old OnEraseBkgnd tricks, but that didn’t appear to help. Other notable apps, such as Visual Studio 2005 don’t show this resizing problem under Vista.

My testing is being done on Vista 64 using the 32bit libraries.

Hi, I am trying to expand a CExtTabPageContainerWnd based on available screen size.
That works OK.

Naturally, I place a dialog into a CExtTabPageContainerWnd and I need to expand that contained dialog also.

I have to use 62 as the y differential to subtract from the CExtTabPageContainerWnd client window size.

How do I know how much the tabs and top overhead are for the CExtTabPageContainerWnd.leaving a true client area for a contained dialog?

Thanks

There is a CExtTabPageContainerWnd::GetSafeTabWindow() method that returns a pointer to the CExtTabWnd window used inside the tab page container. So having the tab window handle, you can retrieve its rectangle.

First the Page container dialog is created.
Next, the contained dialog is created. At this time the tab wnd has a zero client rect
Finally, page insertion occurs. At this point the tab window has a client rect.

Therefore, I would have to adjust the contained dialog window size after page insertion and therefore after OnInitDialog.

So, I would have to "reach" inside the contained dialog code from somewhere else to adjust its window size after OnInitDialog.

Do you have constants somewhere or something that control the tab window size?