Professional UI Solutions
Site Map   /  Register


Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Silence? Collapse All
Subject Author Date
Robert Webb May 5, 2010 - 8:12 PM


Normally Prof-UIS are very good at responding here, but I now have four open items with no reply since between March 23 and April 15.  Three of those have 1 or 2 follow-up nudges, but I’ve had no response to anything since April 15.  The design of this forum makes it very hard to spot where a new post is within a discussion, so here are links to the as-yet-unanswered topics, with brief comment on each:

That discussion was almost sorted, and just waiting on what I think should be a simple answer, and probably a simple fix in the Prof-UIS code as I described.  Not vital to us, but would be nice, and should be very simple.

I expect this probably isn’t too difficult to fix?

Redrawing EVERY view when an MDI tab is clicked is a pretty bad thing, especially if it’s the current tab.  If it’s not the current tab, then only one view moved to the top of the Z order and should be repainted.  There is no RecalcLayout required.  Same when programmatically changing the doc title.  This is more important to us than the previous two, but maybe more involved?

This one is most important to us, but also the most involved.  The ability to change the ribbon bar height is beyond Microsoft’s spec, but would be a great improvement.  Although it’s a significant change, it seems there are only a few things making it impractical at the moment, as discussed in my post.  The height can already be set, but a few things don’t adjust to the change properly.  We’d love to see those few things dealt with.



Technical Support May 12, 2010 - 9:59 AM

It’s not a problem to increase the maximal informativeness level for ribbon elements. Please fine the following line of code in the .../Prof-UIS/Include/ExtToolControlBar.cpp file:

   #define __EXT_RIBBON_ILE_MAX                                                         10

And replace it with the following:
   #define __EXT_RIBBON_ILE_MAX                                                         30

This is the largest possible effective informativeness value and it does not break compatibility with older Prof-UIS versions.

The second question looks like resolved because you can choose between old and new caption trimming mode for ribbon groups. This can be done with overriding the CExtRibbonPage::OnRibbonQueryGroupCaptionTextCompletelyVisible() virtual method. You can also optionally show tooltips over trimmed button group captions and this is controlled by the CExtRibbonPage::OnRibbonQueryGroupCaptionTextWithToolTip() virtual method.

This third problem is only partially related to MDI tabs. The standard Windows MDI interface became half-broken in Windows XP and it’s in the same state in the later Windows versions. The maximized MDI child frames become quickly restored and maximized again when you switching the active MDI child frame. This "improvement" was introduced in Windows XP. As you probably know, Microsoft does not use the MDI interface in its latest products. The Visual Studio .NET and later versions does not use it. The Office 2007/2010 too. We don’t know how the design of the latest Microsoft apps is related to the broken MDI interface, but we had to fix the MDI interface flicker issue in Prof-UIS. We do tiling and cascading manually. We use the screen photo trick when switching the active MDI child frame windows and that’s the source of additional repainting messages. Prof-UIS creates non-painted window over the MDI interface when you switching the active MDI child frame window. This window contains image of the desktop surface under it. The same screen photo approach is used when creating or destroying MDI child fames because the standard MDI interface can also produce the same surprises in these cases.

The last question is the most interesting for us. We have the two big conflicts of the ribbon bar design with the custom height ribbon tab pages: the big buttons with the 32x32 icon and 1..2 lines of text at the bottom and the ribbon galleries. These buttons are incompatible with the ribbon bar containing less than 3 rows of smaller buttons in the ribbon tab pages. The ribbon galleries also cannot be compressed to the less height.

Robert Webb May 25, 2010 - 9:56 PM

Re first question: looks good, 30 is probably sufficient.  Are you making this change in the main distribution?  That’s the main thing.  I don’t want to have to change it with every new version.

Re second question: no, it isn’t resolved.  Please read my other post about it.  I already override that function, which allows ribbon group labels to be truncated EXCEPT when they collapse to a single button.  Then, despite the system trying to save space, they suddenly get bigger as the full text re-appears.  What I’m asking for is that the group label should also be truncated when collapsed to a single button.

Re third question: thanks for the explanation.  Sounds like you won’t be changing it?  It seems at least that when clicking on the current tag that all messages should be avoided as there’s nothing to do.  In particular, if you click on the X to close the current tab, it first insists on redrawing everything in ALL the views.  I’m sure that can be avoided by catching the click and redirecting it as necessary.

Re fourth question: yes, it is the most interesting :-)  We don’t use ribbon galleries at all, so don’t care whether they work, although obviously you will want a generic solution.  Why not just collapse them to a single button as already happens when they get too small.  You can improve that later if necessary, but if the items in the gallery are too tall for the ribbon bar, then there’s probably no choice.

As for 32x32 icons with 1..2 lines ot text below them, I would just say that you can’t have those in a ribbon bar that’s too short.  They should auto-collapse to 16x16 buttons.  This is what we expect, that on a short ribbon bar, no 32x32 icons will appear, rather 1 or 2 rows of 16x16 icons.  Surely that’s what anyone would expect in this situation?

The other thing you need to handle is when ribbon groups collapse into a single button.  Here it insists on using a 32x32 icon.  It needs to use 16x16 instead.

Finally, for our app, we have ribbon bar text fields which are taller than buttons, and will need to know how to change their height.  How do we do that?



Technical Support May 26, 2010 - 12:13 PM

1) Yes, 30 is permanent change. Its already inside Prof-UIS 2.90. You can drop us an e-mail to the support mail box and we will provide you with the download information.

2)The ribbon button, including group buttons, expect to have text containing one or two lines of text only. The expanded group button converts the double line text into single line text. We made the group buttons using ellipsis text effect in the expanded mode. That was your feature request. We can make the same in the collapsed mode. But how should we apply the ellipsis effect in the double line text mode? Should we make ellipsis in both lines? Show we convert the group caption text into single line and then draw it with ellipsis?

3) Needs additional debugging. We think we will be able to remove repainting.

4) We can do this. The ribbon bar/ribbon page should understand and use the new property: the count of rows with the standard small/middle ribbon buttons. Currently this is 3 rows and the problem, that this is very hard coded in all the paint managers and we had carefully debug variable count of rows in Windows XP and later versions using several different DPI screen settings.

5) So, you don’t need 32x32 icons at all in the desired condensed layout of the ribbon bar? This makes the task much easier.

6) We can do this. But 16x16 icons in the collapsed ribbon group button may look like very small relatively to the skin bitmaps of the Office 2007 blue/silver/black themes.

7) The text and combo fields are the CExtBarTextFieldButton buttons. Their size is computed by the CExtBarTextFieldButton::CalculateLayout() virtual method which uses the CExtBarTextFieldButton::OnInplaceControlCalcMarginSizes() virtual method for computing outer margins. By default, the CExtBarTextFieldButton::OnInplaceControlCalcMarginSizes() method returns the CRect(2,2,2,2) margins in pixels. You can override any of these methods to make the text/combo fields smaller.

Robert Webb Jul 6, 2010 - 9:13 PM

Sorry, it’s been my turn to be silent this time!  Here are my thoughts.

1) Great, thanks.

2) The same in collapsed mode would be great.  I’d suggest using ellipsis on both lines, since at least there’s a bit more info then.  The important thing is that my collapsed button isn’t larger than the group when it isn’t collapsed.

3) Thanks.  There are a couple of cases:

    a) Clicking the X should close the tab without redrawing any windows other than those which are exposed by the operation.

    b) Whether or not the child windows are maximised within the frame, all views are redrawn whenever a view is made current.  In this case only the new current view has become more exposed, and it should be the only one redrawn.

4) OK

5) If the ribbon bar is resized too small for a 32x32 icon, then I think the only thing one can expect is that smaller icons will be used instead.  This should probably override other rules too.  Eg, if the programmer has forced an icon to always be large, by removing the small rules, it should still go small if there’s simply not enough height in the ribbon bar for it.

6) That’s fine.  Has to be done though, or the collapsed group button just gets truncated off the bottom.

7) I need to look into this sometime.  I already have those functions overridden and it’s not changing the size of the buttons no matter what I set things to.  I think something else is at play.

So any update on making the ribbon bar height resize nicely?  This is still the thing of most interest to us.  Being able to dock the ribbon bar vertically would be fantastic too, but I’m guessing that won’t happen any time soon.

Other features that we would really find useful are the ability for the user to drag and drop ribbon tabs and groups.  We’ve seen that competitors to our software now have this functionality.  You can even drag a ribbon group out of the ribbon bar, leaving it in a floating window of its own.  I know MS doesn’t do it, and I don’t think BCG or CodeJock support it either, but it would be great for increased usability.  Have you thought about this?



Technical Support May 11, 2010 - 12:59 PM

Yes. Thank you for reminding those issues. We are working on your requests.