Forum

Hi guys, is it possible (or at least reasonably easy) to a preview line to the grid class myself?  I need to build an Outlook style email client and need this type of grid feature.  I know you guys mentioned building similar features yourselves but I need to get started on this feature ASAP.  Thanks for any input,

Chris

I’m working in a MDI environment. I also have a CExtResizableDialog with its own menubar and toolbar. I declared a new accelerator in the accelerators map (for instance CTRL+C) together the function to catch the related message. If I declare the accelerator ID onto the mainframe or onto my document of course I can process the message, but if I declare the function onto my dialog it is never called. I hope this is enought for you to urderstand my problem. (.NET 7.10, ProfUIS library 2.30). Thank in advance.

Roberto Manes

We need more details about your application: Whether the resizable dialog is a pop-up dialog over the MDI frame window or it is a child of some resizable bar? Or may be you are using the child resizable dialog as a view window inside the MDI child frame? Do you use the document/view architecture? Could you let us take a look at the source code which implements a separate accelerator table in your dialog?

Please note that you can have only one menu bar in the scope of one command profile in the command manager. This means your resizable dialog should allocate a separate command profile.

I sent to your support email the complete project. However just to help you a bit more the dialog is a pop-up dialog (style overlapped) over the MDI frame window with its own command profile, menu bar and tools bar. I’m using the document/view architecture. When there are some document opened if the focus is onto a document I can catch the message coming from the accelerator. If the focus is over the dialog (documents opened or closed it makes no difference) I can catch the message only if I select the function from the dialog menu. The accelerator implemented refers to the ID_EDIT_COPY identifier implemented onto both dialog and document menus. Thanks for your help

We sent you an updated project by e-mail. The solution deals only with MFC’s message pre-translation and command routing mechanisms. We added the code that redirects calls of PreTranslareMessage() and OnCmdMsg() from the main frame window to the pop-up non-modal dialog which is now created only on the first demand. This dialog now manages its own accelerator table and uses it in the message pre-translation process. The dialog also sends the WM_CLOSE message to itself at the end of the OnInitDialog() method. This is a tricky technique of initializing the pop-up tool window. We also added layout recalculation to the WM_SIZE handler and made dialog clipping all the child windows.

Hi,
I’ve got an built in ComboBox in a toolbar.
The project is a MDI Doc/View.

How can I fill the combobox with data from the doc/view?
How can I tell the doc/view which item the user has selected in the combobox?

I tried to something like that:

CMainFrame::OnPopupListBoxInitContent
{
...
CFrameWnd* pActiveFrame = GetActiveFrame( );
if (pActiveFrame != NULL) {
CDocument *pActiveDoc = pActiveFrame->GetActiveDocument();

     wndListBox.AddString(pActiveDoc->GetString() );
}
}

In OnTextFieldInplaceTextSet
*pActiveDoc->SetString();

Is there a better way or have you got a sample for that?


Thanks for any advice.

Thanks, now I added RUNTIME_CLASS of document and the menu is switching right! Thnaks for your fast help!!!!
But now I have got another problem: All menuentries, where I have an Icon, there is no menutext displayed. Menuentries without Icon are display right with text. What have I done wrong ???
TIA Willi

Fist of all, please make sure you have invoked the g_CmdManager->UpdateFromMenu() and g_CmdManager->UpdateFromToolbar() methods for all document menu resources and toolbars used in your application. This should be done at the beginning of the CMainFrame::OnCreate() method. If you add these methods, do not forget to clear the system registry before run it again. If some commands do still have only icons in menu and no text, then these commands have been added to in toolbar resources and not been added to menu resources. The solution is to add a new menu resource and update the command manager from it.

Can’t do that in this way, because I have to create the CMainframe, but at this moment I’mnot able to know, what documents are included. Next I load a lot of DLL, which add - according to customer licence - different document types. These DLLs need then Mainframe for adding toolbars. So I added at the end of my InitInstance a call to mainframe, where I use the doctemplate manager, so see what documents are added and call from there the MenuInfoAdd for each document. I solved the problem by g_CmdManager->CmdAllocPtr / g_CmdManager->CmdGetPtr for each missing text. This produce a lot of code. Is there a more easy way to get all texts?
TIA Willi

We may guess that the easiest way to control built-in text/combo fields of the Prof-UIS customization system in the application with an extensible architecture like yours it to teach each document control the text fields. This requires each document to support some interface which can be called from overridden methods of the customize site. We can discuss this idea in details and try to analyze how really easy it is to use it in your application.

Sounds great! What functions do I have to overwrite? Mostly that I can call MenuInfoAdd past start of customisation with EnableCustomization??
TIA Willi

Basically you need to do the following three things with your external documents and views:
1) Let them initialize the customization subsystem, i.e. register menus and etc.
2) Let the active document view detect its menu information’s object name. You should override the CExtCustomizeSite::MenuInfoFindForMenuBar() virtual method in your main frame window like as follows:

CExtCustomizeSite::CCmdMenuInfo * CMainFrame::MenuInfoFindForMenuBar()
{
    ASSERT_VALID( this );
 
    // check special cases
int nMenuInfoCount = MenuInfoGetCount();
    if( nMenuInfoCount == 0 )
        return NULL;
    if(  GetSafeHwnd() == NULL ) 
        return CExtCustomizeSite::MenuInfoGetDefault();
 
    // check whether we are in the cusomize mode
CExtCustomizeSite::CCmdMenuInfo *
        pMenuInfoActiveCustomize =
            CExtCustomizeSite::MenuInfoActiveGet();
    if( pMenuInfoActiveCustomize != NULL )
        return pMenuInfoActiveCustomize;
 
    // ask the active document/view for its menu name
LPCTSTR strMenuName = ...
CExtCustomizeSite::CCmdMenuInfo * pMenuInfo = 
        CExtCustomizeSite::MenuInfoGetByName(
            strMenuName
            );
     ASSERT( pMenuInfo != NULL );
    return pMenuInfo; 
}

3) Optionally let them provide the customization subsystem with data for built-in text fields and combo fields. This can be done by overriding several OnTextField...() and OnPopupListBox...() virtual methods of the CExtCustomizeSite class in your main frame window and passing these invocations to your document/view objects.

Hi,
I have got a ComboBox in a toolbar and customization is enabled.
If the user drop down the listbox and move the mouse over an item,
I would like to see the complete text (like a toolip), because some items
are very long.

Any idea?

Are you talking about tooltips that appear over dropped down list box’s items like tooltips in the tree view common control? Or you would like to see tooltips like rich text tooltips demonstrated in the HelpNotes sample application?

Actually I need tooltips that appear over dropped down list box s items like tooltips in the tree view common control, but tooltips like in your HelpNotes sample would be great.

Also it would be great to format the text in the list box or better to put text in columns or a grid.
e.g. dropped down list box
INFO1 ¦ INFO2 ¦ INFO3 --> Item1
INFO4 ¦ INFO5 ¦ INFO6 --> Item2

We added this feature to our To-Do list. It will be implemented as part of the customization system. Please let us know whether you are pressed for time with regard to this issue.

Thanks for your quick response.

Until you will have implemented that feature it would be great
to size the listbox to the largest item in it and to show a tooltip in the edit field of the combobox if the size of the text is larger than the edit field.

Any idea to that?

By the way:
we are always pressed for time ;-)

Hi,
I have a multi-Doc application with doc/view support. When I use CExtCustomizeSite together with MenuInfoAdd for each document type, the application do NOT switch to the right menu (specific to this document) Without CExtCustomizeSite all works fine. What have I done worng???
TIA Willi

Hi Folks;
My problem is, that I do not get notified by an Tree-Control inserted into an CExtTabPageContainerFlatWnd.

I subclassed from CExtTabPageContainerFlatWnd and inserted an CTreeCtrl into the TabPageContainer. I expect WM_NOTIFY messages to be sent to MyTabWnd, which ist parent of the TreeCtrl. How do I catch the WM_NOTIFY Message that should be sent by the TreeCtrl when the selection changed?

For clarification(?), here are some code-fragments:

CMyTabWnd : public CExtTabPageContainerFlatWnd
{
public:
  Create(CWnd* pParent);
public: 
 CTreeCtrl m_TreeCtrl;
}

CMyTabWnd::Create(CWnd* pParent)
{
 CExtTabPageContainerFlatWnd::Create(pParent);
 
 if( !m_TreeCtrl.Create(
  WS_CHILD|WS_VISIBLE|WS_VSCROLL|WS_HSCROLL|WS_TABSTOP
  |TVS_HASBUTTONS|TVS_HASLINES|TVS_LINESATROOT
  |TVS_INFOTIP|TVS_DISABLEDRAGDROP
  |TVS_SINGLEEXPAND|TVS_SHOWSELALWAYS
  , CRect(0,0,0,0), this, UINT(IDC_STATIC) )
  )
 {
  TRACE0("Failed to create TreeCtrl\n");
  return FALSE;  // fail to create
 }
 m_TreeCtrl.SetFont( CFont::FromHandle( (HFONT)::GetStockObject(DEFAULT_GUI_FONT))

 VERIFY( PageInsert( &m_TreeCtrl, _T("Tree")  ) );

 return TRUE;
}

I tried to overwrite CMyTabWnd::OnNotify(...) but it was never called - overwriting OnHookNotifyMsg(...) did not work either.

Thanks for your help.
Joachim

With my dynamic ControlBars some, have the close button enabled and some do not. This is working fine - I understand that I now need to also implement this in a CExtDynTabControlBar derived class.

How do I display a close button depending on the currently selected tab in a CExtDynTabControlBar ?

I think all I need is to retrieve the currently selected Tab then do something like the following :

void CXPTabPanel::OnNcAreaButtonsReinitialize()
{
    INT nItemCount = CExtDynTabControlBar::GetSwitcherItemCount();
    if(nItemCount)
    {
        CXPPanel * pPanel = (CXPPanel*)GetBarAt(CURRENTLY_SELECTED_TAB,true);
        if(pPanel)
        {
            if(pPanel->HasCloseButton()) NcButtons_Add( m_pCloseButton );
        }
    }


    NcButtons_Add( new CExtBarNcAreaButtonMenu(this) );
}

This would work if I could somehow find the index for CURRENTLY_SELECTED_TAB.

The CExtDynTabControlBar::GetSwitcherItemCount() method returns the number of tab items in the dynamic tabbed bar container, CExtDynTabControlBar::GetSwitcherSelection() returns a zero-based index of the selected tab item, and CExtDynTabControlBar::GetBarAt() returns a pointer to the CExtControlBar window for the specified tab index.

Thanks - ive got the close buttons appearing as desired using:

void CXPTabPanel::OnNcAreaButtonsReinitialize()//OnNcAreaButtonsReinitialize()
{
    INT nCountOfNcButtons = NcButtons_GetCount();

    INT nItemCount = CExtDynTabControlBar::GetSwitcherItemCount();
    LONG nSelection = CExtDynTabControlBar::GetSwitcherSelection();
    if(nItemCount && (nSelection != -1))
    {
        CXPPanel * pPanel = (CXPPanel*)GetBarAt(nSelection,true);
        if(pPanel)
        {
            if(pPanel->HasCloseButton())
            {
                if( nCountOfNcButtons == 0 )
                {
                    m_pCloseButton = new CXPPanelCloseButton(this,m_pFrame,pPanel->GetID());
                    m_pCloseButton->SetCore(m_pCore);
                    NcButtons_Add( m_pCloseButton );
                }
            }
            else
            {
                if( nCountOfNcButtons > 0 )
                {
                    NcButtons_RemoveAll();
                }
            }
        }
    }
}

The problem I have now is removing the panel when the close button is clicked - I want to remove the panel not just hide it.

I have accomplished this using the following overload in my closebutton class

    virtual bool OnNcAreaClicked( CPoint point )
    {
        ASSERT_VALID( this );
        // They clicked the button i think
        if(!m_rc.PtInRect(point))return false;

        RemovePanel();
        return true; // continue asking nc-buttins
    }

My RemovePanel function uses the RemoveControlBar method. This works fine unless the control bar is tabbed - the control bar gets removed as desired when the close button is clicked however if I then drag the remaining control bar and try to tab it with another I get an application crash with the following debug info:

mfc71ud.dll!CObject::IsKindOf(const CRuntimeClass * pClass=0x007776d8) Line 44 + 0x8    C++
ProfUIS230ud.dll!0050de2a()     
ProfUIS230ud.dll!004d4800()     
ProfUIS230ud.dll!0050ce18()     
ProfUIS230ud.dll!0050fc12()     
ProfUIS230ud.dll!0050f9c3()     
ProfUIS230ud.dll!004feec5()     
ProfUIS230ud.dll!004fba61()     

There is not enough to call the CFrameWnd::RemoveControlBar() method because MFC’s frame window knows nothing about internal implementation of tabbed bar groups in Prof-UIS. Here is the source code which removes the resizable control bar specified by pBar regardless of its state:

CMiniDockFrameWnd * pMiniFrame = NULL;
 if( pBar->IsFloating() )
 {
  pMiniFrame = 
   DYNAMIC_DOWNCAST(
    CMiniDockFrameWnd,
    pBar->GetDockingFrame()
    );
  ASSERT_VALID( pMiniFrame );
 } // if( pBar->IsFloating() )
 else
 {
  ASSERT( ! pBar->m_pDockBar->m_bFloating );
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
  if( pBar->AutoHideModeGet() )
  {
   ASSERT_KINDOF( CExtDockBar, pBar->m_pDockBar );
   CExtDynAutoHideArea * pWndAutoHideArea =
    ((CExtDockBar*)pBar->m_pDockBar)->_GetAutoHideArea();
   ASSERT_VALID( pWndAutoHideArea );
   CExtDynAutoHideSlider * pWndSlider =
    pWndAutoHideArea->GetAutoHideSlider();
   ASSERT_VALID( pWndSlider );
   if( (pWndSlider->GetStyle()&WS_VISIBLE) != 0 )
    pWndSlider->SendMessage( WM_CANCELMODE );
   pWndAutoHideArea->RemoveControlBar( pBar, true );
  } // if( pBar->AutoHideModeGet() )
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
  if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockBar)) )
  {
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
   if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockDynTabBar)) )
   {
    CExtDynTabControlBar * pTabbedBar =
     STATIC_DOWNCAST(
      CExtDynTabControlBar,
      pBar->m_pDockBar->GetParent()
      );
    LONG nIdx = pTabbedBar->FindControlBar( pBar );
    if( nIdx >= 0 )
    {
     LONG nSel = pTabbedBar->GetSwitcherSelection();
     if( nIdx != nSel )
      pTabbedBar->SetSwitcherSelection( nIdx );
     pTabbedBar->RemoveSelFromSwitcher();
    } // if( nIdx >= 0 )
   } // if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockDynTabBar)) )
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
   VERIFY(
    ((CExtDockBar *)pBar->m_pDockBar)->
     RemoveControlBar( pBar, -1, 0, false )
    );
  }
  else
  {
   VERIFY( pBar->m_pDockBar->RemoveControlBar(pBar) );
  }
 } // else from if( pBar->IsFloating() )
 pDockSite->RemoveControlBar( pBar );
 pBar->m_pDockSite = NULL;
 pBar->m_pDockBar = NULL;
 m_mapBars.RemoveKey( pBar );
 if( pMiniFrame != NULL )
  pMiniFrame->DestroyWindow();
 else
  pBar->DestroyWindow();
 if( ! bForceNoOptimizeMode )
  CExtDockBar::_OptimizeCircles( pDockSite );

Thats Great thanks - It fixes most of my problem however I have had to comment out two parts to get it going :

pDockSite variable is undefined.

I also get an unknown variable error for bForceNoOptimizeMode.

Thanks again

Ive also noticed that a Control Bar doesnt get removed under the following conditions when there are 2 control bars (A and B) which are initially separate from each other (not tabbed ):

1) Drag A onto B - B becomes the selected tab.
2) Select A’s tab and drag so that it is docked below B.
3) Close B using the Removal code above.

When I do this B doesnt get removed.

Also please could you clarify what m_mapBars is?

We will certainly check this issue. We took the source code for removing control bars in any state from the new CExtDynamicBarSite class and can say that we did not encounter any problems with allocating/deallocating resizable bars dynamically. m_mapBars is used for keeping pointers to bar objects as key values in the map. Please let us know what happens with the control bar that fails to be removed? Is it accessible UI part like any other bars? Do you have any assertions?

The control bar doesnt remain as a fully functional control bar.

Upon closing it - the title string disappears but the bar remains.

It can be floated, however when it is dragged to be docked /tabbed with any other bars it disappears.

There are no asserts at any stage.

Could you send us your project or the entire code snippet/method that removes the control bar?

void CMainFrame::RemovePanel(CXPPanel *pBar)
{


CMiniDockFrameWnd * pMiniFrame = NULL;
if( pBar->IsFloating() )
{
    pMiniFrame = DYNAMIC_DOWNCAST( CMiniDockFrameWnd, pBar->GetDockingFrame() );
    ASSERT_VALID( pMiniFrame );
} // if( pBar->IsFloating() )
else
{
    ASSERT( ! pBar->m_pDockBar->m_bFloating );
    #if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
    if( pBar->AutoHideModeGet() )
    {
        ASSERT_KINDOF( CExtDockBar, pBar->m_pDockBar );
        CExtDynAutoHideArea * pWndAutoHideArea = ((CExtDockBar*)pBar->m_pDockBar)->_GetAutoHideArea();
        ASSERT_VALID( pWndAutoHideArea );
        CExtDynAutoHideSlider * pWndSlider = pWndAutoHideArea->GetAutoHideSlider();
        ASSERT_VALID( pWndSlider );
        if( (pWndSlider->GetStyle()&WS_VISIBLE) != 0 )
        {
            pWndSlider->SendMessage( WM_CANCELMODE );
        }
        pWndAutoHideArea->RemoveControlBar( pBar, true );
    } // if( pBar->AutoHideModeGet() )
    #endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
    if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockBar)) )
    {
        #if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
            if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockDynTabBar)) )
            {
                
                CExtDynTabControlBar * pDynTabbedBar = STATIC_DOWNCAST( CExtDynTabControlBar, pBar->m_pDockBar->GetParent() );
                CXPTabPanel * pTabbedBar = (CXPTabPanel *) pDynTabbedBar;

                LONG nIdx = pTabbedBar->FindControlBar( pBar );
                if( nIdx >= 0 )
                {
                    LONG nSel = pTabbedBar->GetSwitcherSelection();
                    if( nIdx != nSel )
                    {
                        pTabbedBar->SetSwitcherSelection( nIdx );
                    }
                    pTabbedBar->RemoveSelFromSwitcher();

                    if(pTabbedBar->GetSwitcherItemCount() > 0)
                    {
                        pTabbedBar->SetSwitcherSelection(0);
                    }

                    pTabbedBar->OnNcAreaButtonsReinitialize();

                } // if( nIdx >= 0 )

            } // if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockDynTabBar)) )
        #endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
        VERIFY( ((CExtDockBar *)pBar->m_pDockBar)->RemoveControlBar( pBar, -1, 0, false ) );
    }
    else
    {
        VERIFY( pBar->m_pDockBar->RemoveControlBar(pBar) );
    }
} // else from if( pBar->IsFloating() )


RemoveControlBar( pBar );
pBar->m_pDockSite    = NULL;
pBar->m_pDockBar    = NULL;


if( pMiniFrame != NULL )
    pMiniFrame->DestroyWindow();
else
    pBar->DestroyWindow();

CExtDockBar::_OptimizeCircles( this);


RecalcLayout();

}

 

I’m using the CExtMenuControlBar.  The menu is oriented from left to right.  When I change the screen saver properties(change from 10 to start to 9 minutes to start) and press ok, the menu bar orients itself top to bottom.  I beleive this is also happening when the screen saver becomes active.

I tested it in your sample applications and the same things happen.

Please help!

Is there an easy way to retrieve the positions (relative to other control bars etc) of a given control bar.

I am intending to add storage of control bar positions at shutdown of my application.

Im hoping to be able to build up a hierarchy string describing the layout, which can be stored and retrieved on app startup.

To accomplish this i need to be able to retrieve the Control Bars parent control bar in the layout (if it is the main CView then this will be null). And the relative dock position to its parent e.g tabbed,docked left,docked top etc,

Thanks.

The internal structure of resizable bars is tree-based. Please try to carry out the following experiment.

1. Uncomment these lines at the beginning of the ...\Src\ExtDockBar.h file:

   /// #define __DEBUG_PAINTING_AREAS_DOCKBAR__
   /// #define __DEBUG_PAINTING_AREAS_EXTRESIZABLEBAR__

2. Rebuild Prof-UIS.
3. Build and run any application with several resizable control bars.

You will see yellow and magenta margins near right/bottom sides of all control bars and their container windows (a.k.a. dock bars). The structure of these windows is always tree-like. This can be control bars’ containers at some nested level near any side of the main frame window. This can also be containers inside a compound floating mini-frame window. Due to this complexity, we decided not to provide a mechanism for saving bar states in form of named parameters into simple property bag like like INI/XML files. The resizable control bars’ state is serialized into MFC archives in binary form and it is assumed that the control bars are created using the data corresponding to the same control bars that were serialized before. We think that this design does not add any limitations to your application. If you need more complex bar mechanism for allocating control bars, then you can use new dynamic resizable bars introduced in the Prof-UIS 2.31 minor release. In any case, we can discuss your task in details and we will help you find the easiest solution.

Im not sure how that helps unfortunatley...

A bit of information about my application:

I am creating CExtControlBar derived "panels" dynamically at runtime, this is working fine.

Is there a way I can retrieve the posittions of these panels relative to the main View at shutdown?

You can get window rectangles of all the control bars but they cannot be used for restoring control bar positions because the API for docking resizable control bars with each other is not based on window rectangles. Why are you restricted to XML/text formats for saving/restoring control bar positions?

Im not necessarily restricted to xml/textual format storage - any format will probably be ok, just as long as Im able to match a control bar with a custom id that my app specifies at runtime which can then in trun be matched back again when the ap is reloaded.

How do you suggest retrieving the dock positions?

Hi Customer Support,

I have a MDI application. When it starts, it will have one menu where the user can just login, see About or Exit the application. However, when the user logs-in, I would like to assign a different Menus to the application based on his access rights. I had used the following lines of code in pure MFC application but it does not work with Prof-UIS. Could you pleaseme know what I should do to make it work:

Thanks,

Saroj

 

void CMainFrame::onApplicationLogin()

{

CUserLoginDlg dlgApplicationLogin;

CMenu AdminMenu;

if(dlgApplicationLogin.DoModal() == IDOK)

{

intLoginLevel = dlgApplicationLogin.GetAccessLevel();

switch(intLoginLevel)

{

case OPTIVIEW_USER_LEVEL1:

AdminMenu.LoadMenu(IDR_USER1_MENU);

SetMenu(&AdminMenu);

AdminMenu.Detach();

break;

case OPTIVIEW_ADMIN_LEVEL:

AdminMenu.LoadMenu(IDR_DRAWCLTYPE);

SetMenu(&AdminMenu);

AdminMenu.Detach();

break;

}

}

}

The source code you provided will work correctly only if the CWnd::SetMenu() method is called for the main frame window before the CExtMenuControlBar window is created. To provide you with advice or a solution, we need more details: Is your application MDI or SDI and whether the document view architecture is used? Is it customizable, i.e. whether the CExtCustomizeSite class is used in your project?

Hi,

I have already created the menubar in OnCreate() function in the MainFrame window. So the menu is already created. And that time the menu is very simple one with not a whole lot of options. When the user logs-in, he will do so by selecting one of the menu option available at that time.

1.  My application is MDI modified from your DrawCLI sample application.

2.  CExtCustomizeSite is used in my application.

3.  Document view architecture is definitely used.

Please let me know if you need further information.

Regards,

Saroj

 

The application configuration used in your project allows you to implement any number of menu lines for any number of users easily. Your application initializes the instance of CExtCustomizeSite in CMainFrame::OnCreate() in which all the menu lines are registered by calling the CExtCustomizeSite::MenuInfoAdd() methods. You can add more invocations of this method to register any required number of menu lines for all user types. To make menu bar using appropriate named menu line, override the CExtCustomizeSite::MenuInfoFindForMenuBar() virtual method like as follows:

CExtCustomizeSite::CCmdMenuInfo *
    CMainFrame::MenuInfoFindForMenuBar()
{
    ASSERT( this != NULL );
    // if we are in the customize mode
CCmdMenuInfo * pMenuInfo =
        MenuInfoActiveGet();
    if( pMenuInfo != NULL )
        return pMenuInfo;
    // in other case we need to return
    // an appropriate menu line
    pMenuInfo =
        MenuInfoGetByName(
            _T("Appropriate Name")
            );
    return pMenuInfo;
}

Of course, this approach assumes your code knows names of all menus registered in the customize site and simply returns the menu info object which corresponds to the currently logged in user type.

Hi,

I added the following lines of code in my OnCreate() function of MainFrame.cpp to add the menu resource. But I get an ASSERT at line #2666 of ExtCustomize.cpp file.

VERIFY(CExtCustomizeSite::MenuInfoAdd(this, _T("Default"), IDR_MAINFRAME, true, false, RUNTIME_CLASS(CMainFrame)) );

VERIFY(CExtCustomizeSite::MenuInfoAdd(this, _T("AdministratorMenu"), IDR_DRAWCLTYPE, false, false, RUNTIME_CLASS(CMDIChildWnd), RUNTIME_CLASS(CView), RUNTIME_CLASS(CDocument)) );

VERIFY(CExtCustomizeSite::MenuInfoAdd(this, _T("UserLevel1Menu"), IDR_USER1_MENU, false, false);

Please help me to get this problem resolved.

Saroj

Hi,

how can I disable/enable a popup menu in a menu?

1) In OnExtMenuPrepare I tried

INT Pos = pPopup->ItemFindByText(_T("My_PopupMenuItem"));
if(Pos != -1) {
CExtPopupMenuWnd::MENUITEMDATA & _md = pPopup->ItemGetInfo( Pos );
_md.Enable(false);
}

but it does not work. It only works for MenuItems with Cmds.

By the way, I don’t like to find the item by text.
Is it possible to get the pos by ItemFindPosForCmdID.

2) Nice would be to handle that in an on_update_command_ui.

Thanks for your help

I added the following code to make my menu bar static and immoveable.

/* m_wndMenuBar.EnableDocking(CBRS_ALIGN_TOP);

if( !CExtControlBar::FrameEnableDocking(this) )

return -1;*/

//DockControlBar(&m_wndMenuBar);

But, I’d the gripper to show up anyway since it gives the menu a more modern look.  How can I do this?

Sorry I was in a rush when I posted.  The code referenced in my post is commented out in my project thus my menu bar is static and can’t be moved.  This is my intention. 

However, I’d still like to know how to make the menu bar draw the gripper graphic when the menu is not moveable. 

Thanks.

How do I change the font size in the tabs?

Hi,

I want to show icon with text on some of the toolbar buttons using CExtCmdItem::m_sToolbarText. Everything is working fine, but when I add CExtCustomizeSite::EnableCustomization(), all buttons are shown without text to the right. How can I setup a configuration where text for some buttons is shown?

If your application is customizable (i.e., based on CExtCustomizeSite), any command item in menus/toolbars has two command tree nodes: the initial and the customized. The initial node is used to reset the properties of a command tree node in the customize mode (when the Customize dialog is open and the user can edit/reset any command properties). The command tree nodes are implemented as instances of the CExtCustomizeCmdTreeNode class. You can get both initial and customized command tree nodes for each toolbar button and change the display style of the button to Text and image. In your case, the text in toolbar is not visible because the default display style of all the command tree nodes is not Text and image.

Here is a code snippet that demonstrates how it can be done:

 
void CMainFrame::_SetCmdStateTextAndImage
   ( CExtToolControlBar * pBar, UINT nCmdID )
{
// get the root command tree nodes for toolbar 
// (children nodes of these roots are representing 
// command buttons in toolbar) 
CExtCustomizeCmdTreeNode * pNodeRootInitial = 
      CExtCustomizeSite::GetToolbarCmdNode( 
            pBar, 
            true 
            ); 
ASSERT_VALID( pNodeRootInitial ); 
CExtCustomizeCmdTreeNode * pNodeRootCurrent = 
      CExtCustomizeSite::GetToolbarCmdNode( 
            pBar, 
            false            
            ); 
ASSERT_VALID( pNodeRootCurrent ); 
 
// get the command tree nodes for the 
// toolbar button with command nCmdID 
CExtCustomizeCmdTreeNode * pNodeButtonInitial = 
      pNodeRootInitial->ElementAt(
            pNodeRootInitial->SearchNode( nCmdID )
            );
ASSERT_VALID( pNodeButtonInitial ); 
 
CExtCustomizeCmdTreeNode * pNodeButtonCurrent = 
      pNodeRootCurrent->ElementAt( 
            pNodeRootCurrent->SearchNode( nCmdID )
            ); 
ASSERT_VALID( pNodeButtonCurrent ); 
 
// change display style of button’s nodes 
// (remove display style flags and then assign new) 
pNodeButtonInitial->ModifyFlags( 0, __ECTN_DISPLAY_MASK ); 
pNodeButtonCurrent->ModifyFlags( 0, __ECTN_DISPLAY_MASK ); 
pNodeButtonInitial->ModifyFlags( __ECTN_DISPLAY_TEXT_AND_IMAGE ); 
pNodeButtonCurrent->ModifyFlags( __ECTN_DISPLAY_TEXT_AND_IMAGE ); 
}

Hi

I think there is a bug in the menu implementation, try this:

- Use mouse and open a menu from the main manu bar containing at least 1 sub menu.

- Click on Sub menu

- Then Click on a disabled menu above or below Sub menu text.

- Application is now unresponsive to any mous movements/clicks.

- Only way to regain control is to switch focus to other app or os, then menu closes.

 

Regards

Arild

Thank you for the bug report. It is not difficult to fix it. Please find the following code in the CExtPopupMenuWnd::_OnMouseClick() method which is defined in the ExtPopupMenuWnd.cpp file:

    MENUITEMDATA & mi = _GetItemRef(nHitTest);
    if( (!mi.IsEnabled()) || mi.IsSeparator() )
        return true;

and replace that with the following code:

    MENUITEMDATA & mi = _GetItemRef(nHitTest);
    if( (!mi.IsEnabled()) || mi.IsSeparator() )
    {
        _ItemFocusCancel( TRUE );
        _SetCapture();
        return true;
    }

Of course, we can provide you with the latest source code via e-mail or FTP download.

Dear support team,

is it possible to have a hidden autohide controlbar to reappear only on mouse click not with only hovering? Sometimes it is confusing if a bar floats over the document by just coincidentally moving the mouse over a tab pad.

Thanks in advance.

 

Axel

 

Hi Technical Support,

I am using a treeview from your sample application for my application and it working great. However, I have noticed few limitations with this and would like to seek your help.

When you right click on an item currently not selected, the selection momentorialy goes to the new selection and then goes back to the old selection when the Pop-up menu is displayed. This is a probelm for me because I wanted to make the selection where the Right mouse button was clicked. Can you help me to resolve this problem ?

I noticed similar behaviour in your sample applications as well.

I appreciate your help.

Regards,

Saroj

The behavior you described is standard for the tree control. When you receive the right mouse click message (or WM_CONTEXTMENU) you can get coordinates of the mouse pointer, call the HitTest method to determine the tree item at the specified point, and select it by hand. This will allow you make the item selected after the pop-up menu is closed.

void CMyTree::OnRclick(NMHDR* pNMHDR, LRESULT* pResult) 
{
   UINT nFlags;
   CPoint curPoint;
   GetCursorPos(&curPoint);
   ScreenToClient(&curPoint);
 
   HTREEITEM hCurrentItem = HitTest(curPoint, &nFlags);
   if(hCurrentItem != NULL)
   {
      SelectItem(hCurrentItem) ;
 
// show context menu
      }
*pResult = 1;
}

Working with ProfUIS 2.32.

Problem #1: Tab-docked control bars don’t get visibility correct when Autohidden

I notice that when ControlBars are tab-docked together and AutoHidden, CControlBar::IsVisible() always returns 1.
When a ControlBar is AutoHidden by itself (not tab-docked with any other bar), CControlBar::IsVisible() returns 0.

Problem #2 (possibly related to #1): Autohide controlBar will "grab" all other hidden controlbars that are tab-docked with it, and show their tabs, regardless of their visibility state.

To reproduce in MDI_DynamicBars project:
-Tab-dock Bar4 and Bar5 together
-Close Bar4
-Autohide Bar5

You’ll see that Autohide tabs appear for Bar5 (good) AND Bar4 (wrong, should be hidden). The Autohide tab for Bar4 should not appear until pBar4->BarStateSet( pBar4->BarStateGet(), TRUE) is called.

Is it possible to get a workaround to these problems? Thanks!

If you are using CExtDynamicControlBar-based bars based on the CExtDynamicBarSite instance, just use the CExtDynamicControlBar::BarStateGet() method which returns both the state of the control bar and visibility flag in this state.

In case of ordinary non-dynamic control bars, there is no such a convenient method. The control bar in the auto-hide mode is the ordinary control bar, which is hidden, the auto-hide flag is turned on and it has the associated tab item in the grouped auto-hide tabs area. So, you need to start analyzing the state of such a control bar with the CExtControlBar::AutoHideModeGet() method.

As for auto-hide tab behavior, we cannot say that this is a bug but rather particular implementation of resizable control bars in Prof-UIS. If you believe that this should be changed in a way you described we are ready to discuss this.

It makes sense to use BarStateGet() instead of IsVisible(): you definitely have behaviour above and beyond standard MFC controlbars that deserves its own method.

I believe however, that if a control bar is hidden, it should always remain hidden until we request to show it.
In the case I describe above, Bar4 becomes "visible" (we can see its autohide tab) simply because it happened to be tab-docked with another controlbar that is being auto-hidden.

Under this condition, I believe that Bar 4 should remain hidden, but should remain tab-docked with Bar5. This way, once I make Bar4 visible, it remains tab-docked with Bar5. Since Bar5 is currently auto-hidden, Bar4 should also be in the same auto-hide state, and we should now see an additional Auto-hide tab for Bar4.

I’m guessing that your current approach is that tab-docked control bars act together as a "group": close one, and you close them all. Show one, and you show them all.
I agree that their docking state should be a "group decision": since the user has decided to group them together, they should travel together (auto-hide, floating, etc).
My point is that I believe control bar visibility is not a "group decision", they should be individually controlled.

We tend to agree with your point of view with regard to improving the behavior of resizable control bars that are tab-docked and added this issue to our to-do list. Such independent control of control bars’ visibility may be convenient.

I also found that a similar visibility problem also occurs when floating tab-docked controlbars together: close the floating window (use "X" button), and I find that BarGetState(&isVisibile) returns (isVisible == true), which is wrong.

Perhaps if you could try something to your sample project MDI_DynamicBars, you’ll get a chance to see how controlbar visibility isn’t quite right yet, and will also demonstrate the issues that I’ve raised:
Currently, r/click popup-menus list all toolbar and controlbar names (and their icons), but do not indicate controlbar visibility status (as is done with toolbars). Selecting a controlBar will make it visible (if it was hidden), but the inverse it not true: it does not close the control bar.

If you made the r/click menu behave the same way for controlbars as it does for toolbars (indicate and TOGGLE visibility state), this should demonstrate these issues well. Heck, it would also make this superb example even better!

The toolbars (CExtToolControlBar) and other fixed size control bars including the panel control bar (CExtPanelControlBar), menu bar (CExtMenuControlBar) and status bar (CExtStatusControlBar) are docked next to outside frames. All these control bar types use the show-hide behavior of their commands and Prof-UIS automatically generates checked-states of all the commands corresponding to the fixed size bars. As for resizable control bars (CExtControlBar, CExtDynamicControlBar) they can show two types of behavior regarding to show/hide commands:

1) Old style behavior which you can use only if the auto-hide feature is not enabled for the frame window, i.e. you do not call the CExtControlBar::FrameInjectAutoHideAreas() method. This behavior is absolutely similar to the behavior of commands corresponding to the fixed size control bars.

2) New style behavior introduced in Visual Studio .NET. It can be described as one-way action. By performing the command corresponding to a resizable control bar, you can only show this bar and set focus onto the child window of this control bar. If the auto-hide feature is enabled in your application, such behavior is mandatory.

The CFrameWnd class has two handy methods which you can use in the message map entries of your frame windows: OnBarCheck() and OnUpdateControlBarMenu(). These methods implement the old style command behavior for control bars. You cannot use these methods with resizable control bars when the auto-hide feature is enabled. So, in many our samples we re-defined these methods in the CMainFrame class. Here is our version of these methods:

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

If we change the definition of the USE_OLD_STYLE preprocessor symbol to true, then these methods will work like the same methods in the CFrameWnd class.

We will additionally check the "X" button click problem for complex floating palettes.

1. Can I get a suggested workaround to the tab-docking visibility issue when autohiding CExtDynamicControlBar?


2. Yes, I can understand the differing functionality of OnUpdateControlBarMenu() and OnBarCheck(), and how to modify their behaviour when enabling Autohiding.
However, your sample project MDI_DynamicBars does not display visibility status of each CExtDynamicControlBar, nor does the code toggle visibility: it only *shows* control bars, does not hide them.

By example, r-click in toolbar area: popup menu shows a checkmark if toolbar is visible, no checkmark if toolbar hidden. Selecting "Toolbar" menu option will toggle visibility.

My point was that if you performed the same functionality for all CExtDynamicControlBar, this will demonstrate the visibility problems that I describe.


3. It has become very confusing as to how to check visibility of CExtDynamicControlBar, and how to toggle visibility. A working sample would greatly clarify and demonstrate the correct implementation.

By example, this no longer works correctly:
MyCExtDynamicControlBar::OnFrameBarCheckUpdate()
{
...
pCmdUI->SetCheck( (GetStyle() & WS_VISIBLE) != 0 );
...
}

And under the circumstances I mentioned earlier, neither does this:
BOOL IsControlBarVisible()
{
bool bIsVisibleState = false;
BarStateGet(&bIsVisibleState))
return bIsVisibleState? TRUE : FALSE;
}

So, can you advise what is the correct technique to check for visibilty of CExtDynamicControlBar? How would you implement IsControlBarVisible()?

Please let us to simplify and clarify your current task description before we will provide you with the ready-to-use solution: everything is OK, but you want to see check marks on the resizable bar commands even if auto-hide feature is enabled. Is that what you need right now?

No.
I thought it would have been useful to demonstrate how BarStateGet(&bIsVisible) returns the wrong values under certain circumstances, but I no longer believe it will solve the problems we’re trying to solve, and I’ve also veered waaaaay off track. So let’s backup a bit....

Your implementation emulates VS .NET behaviour, and VS.NET does not show checkmarks for visible controlbars: So, your sample project emulates VS.NET behaviour (good!) except for the following. So, what I really need are these 2 items:


1. A fix for the problem originally posted in this thread:

"To reproduce in MDI_DynamicBars project:
-Tab-dock Bar4 and Bar5 together
-close Bar4 (use "X" button on NCarea)
-Autohide Bar5
You’ll see that Autohide tabs appear for Bar5 (good) AND Bar4 (wrong)."

I can also duplicate same condition when closing Bar4 with BarStateSet( BarStateGet(), false ) instead of close button.

VS .NET doesn’t behave this way, I don’t believe ProfUIS should either. If you disagree, that’s fine, but could you please show me how I can work around this?


2. A fix for BarGetState(), or a demonstration of how to implement CExtDynamicControlBar::IsControlBarVisible() that works for all possible states.

As mentioned earlier in this thread:
"when floating tab-docked controlbars together: close the floating frame window (use "X" button), and I find that BarGetState(&isVisibile) returns (isVisible == true), which is wrong."

Are there any known issues with running a Prof-uis application on a tablat pc running windows xp tablet edition?

My application frequently locks up/crashes when running on this OS.