Forum

About 8 months ago I asked about changing the ribbon bar height (see http://www.prof-uis.com/prof-uis/tech-support/support-forum/customisable-ribbon-bar-64944.aspx).  We would still love to be able to do this, since a number of our customers are complaining about it taking up too much space, so I thought it best to start a new thread.

Back then you advised that we override CExtRibbonPage::RibbonLayout_GetGroupHeight(), and indeed this goes part of the way.  It does indeed allow us to change the height of the ribbon bar, however Prof-UIS fails to use this height properly.  I notice the following problems:

- The ribbon groups are simply truncated, not resized, so the border around a group just gets cropped meaning you can no longer see the group name, nor the lower right group button if it has one.

- Large icons are still used, although they no longer fit.  Once below a certain height, all icons should be forced to small.

- Although it does seem to arrange buttons into less rows as it should (ie 1 or 2 instead of 3 depending on height), they are still being positioned vertically based on the original full height.  So it may decide to use a single row, but they are "centred" so low that they are mostly clipped by the actual new bottom of the ribbon bar.  Maybe this and the previous item would sort themselves out if the groups were resized correctly?

Would it be possible to fix these things?

Thanks,

Rob.

The CExtRibbonButtonGroup::OnRibbonCalcCollapsedGroupSize() virtual method computes the size of a ribbon button representing the collapsed group of buttons. This button is the same group container button but it’s in the top-collapsed state (CExtRibbonButtonGroup::TopCollapsedStateGet()). You need to code your own CExtRibbonButtonGroup-derived and CExtRibbonButtonToolGroup-derived classes which implement the CExtRibbonButtonGroup::OnRibbonCalcCollapsedGroupSize() virtual method. You will also need to code your own group and tool-group ribbon command nodes which will provide the ribbon bar with your group button class instances. The same can be done for the text/combo field buttons and their ribbon nodes.

The ribbon bar height changing means complete reset of layout rules for all the ribbon elements. We are not sure it’s always possible to find the best looking layout rules for any abstract height of the ribbon bar.

Sorry, but I’m not sure how to tie all this together from that description.  Is there any sample code?  I couldn’t find anything that does something similar already.  These work-arounds seem like things Prof-UIS should do internally, but I’m happy with any solution I can get working.

You’re right that it may not always be possible to find a good layout, depending on the contents, but I only see a few problems which seem like they should be within reach.

Also, you didn’t comment on how best to prevent use of large icons.  I’m calling RuleRemoveLargeILV() for every node, which then makes it hard to bring the large icons back if the user changes back to a taller ribbon bar.  Is there a better way?

Thanks,

Rob.

We followed the Microsoft’s Ribbon UI Design Guidelines document when we coded all the CExtRibbon*** classes. So, a custom sized ribbon is some kind of advanced, non-standard and custom coded task. But we think this task is really interesting and creative. We would be very happy to code some test project for you and/or similar new sample application for Prof-UIS. Please let us discuss the entire task details. We understand this improved ribbon bar should support any variable height and it should place all the buttons automatically to fit any available space in each ribbon button group. But what is the custom ribbon size in your real application? Should we insert some separator at the bottom of the ribbon and let the user to resize the ribbon bar to any height? Or do we need to support some non-standard ribbon bar size(s) which will make the ribbon bar to place the ribbon elements of the current standard size into layouts which are different than the standard three row layout? In the last case, we can modify the Prof-UIS ribbon source code and let you to specify the count of the standard sized ribbon rows you want to see.

Sounds great.  It’s already close, other than the few things I mentioned.  For our purposes, I’d be happy for the user to be able to choose somewhere between 1, 2 or 3 rows of small icons.  There’s nothing much to gain by setting the height to intermediate values.  It would be a nice addition if the user could interactively grab the bottom of the ribbon bar and drag it up or down, maybe snapping to sensible heights to fit integral numbers of icon rows, but we’re also happy to add our own interface control and use the current programmatic way to set the height.

Buttons already arrange themselves into just 1 or 2 rows when the height is reduced.  They even arrange into more rows when the height is increased.  But they still insist on trying to use large icons when there’s not enough room, and when groups collapse to single buttons it really throws things out.

The formula for a good height seems to be: dh = rows * 19 - 67, where dh is the change in height, added to the value returned by the base class versiono of RibbonLayout_GetGroupHeight().  This presumes only small icons are used, which should be true for 1 or 2 rows.  For 3 rows this formula gives -10, ie 10 pixels shorter than usual, which fits 3 small rows OK, but doesn’t quite fit one large button with text below.

I’m still not sure how to make my ribbon bar text fields shorter too.  Currently they are taller than buttons and thus cause problems when using a different ribbon bar height.

Rob.

Any further news on this?  (My Outlook isn’t working by the way, in case you’ve tried emailing me).

Rob.

If you are using a non-standard height for the ribbon bar, you should not use ribbon button in the large state because large buttons are optimized for the standard ribbon height only. You should remove large button states from all the ribbon command tree nodes. If you decrease the ribbon bar height, there is no vertical space to organize buttons into 3 rows. Of course, you will see 2 or 1 rows of buttons only. Big buttons in some ribbon group make all the groups in the tab page larger. That’s why you see incorrectly clipped layout.

Wow, using RibbonILE_RuleRemoveLargeILV() on every ribbon bar node almost fixes everything, but not quite.  I still notice these limitations:

- When a ribbon group runs out of room and switches to a single drop-down button, this button is too big and forces the whole ribbon page to be bigger, again getting truncated at the bottom.  This single button has text below, whereas it would fit if the text was put beside it when there isn’t enough vertical room (and maybe the button itself would need to be smaller in those cases).

- I want to make the ribbon bar height available to the user.  It looks like when they make the bar shorter I will have to call RibbonILE_RuleRemoveLargeILV() for every node.  What about when they make it bigger again?  How do I bring back that rule for all the nodes that had it originally?  Surely Prof-UIS should recognise when the height is too short for large icons and behave as if they had been removed.  I imagine this would be much easier on your end than the end-user’s.

- I have text/combo fields on some ribbon pages.  These it seems are taller than normal buttons, and don’t fit in so well at shorter heights chosen based on button height.  Is there a way I can change the height of my text fields?  They seem taller than necessary anyway.  I create a new CExtRibbonNode, then call ModifyFlags(__ECTN_TBB_TEXT_FIELD | __ECTN_TBB_RESIZABLE), but I don’t see any way to specify a height.  The node is not derived from a CWnd.

I discovered that making the bar 29 pixels shorter works well for 2 rows of small icons, and 48 shorter for 1 row.  Works well except for the above problems.

Thanks,

Rob.

Any solutions to the above three issues?  The ability to reduce the ribbon bar to one or two rows of (small) buttons is great, but really unusable as it stuffs up when a group is reduced to a single button that’s too big.

Thanks,

Rob.