Forum

Hello, we bought your ProfUIS toolkit and are having several problems.

First some background. We are using a class derived from CExtToolControlBar class for all our toolbars. This uses a class derived from CExtBarButton for all the buttons. This is because we need true disabled icons, not just grayscale, so the derived class does its own painting using separate enabled and disabled bitmaps. This button class also can display text to the right of the icon (instead of at the bottom), which we need for one of our toolbars.

Problem 1) One of our bars uses this right-of-icon text display, with about 50 buttons on the bar. Initially this bar is docked vertically on the left. When I float it, it becomes a huge full screen window, with left-over junk the client area, and the toolbar along the top until it gets truncated way over on the right, off the screen.

If you then attempt to resize the huge frame, it pops almost off the right edge of the screen.

It appears that it tries to force a horizontal arrangment, something like 4600x12 pixels. But it never resizes the minidockframe to fit. I don’t understand why this doesn’t wrap, unlike the other bars which float and wrap to reasonable sizes.

I’ve tried resetting sizes in the toolbar _CalcSize(), WrapToolBarH(), WrapToolBarV(), and SizeToolBar, to no avail. Show stopper, to say the least.

Curiously, if I force all the buttons to be wide, by putting _size.cx *= 5 in the CExtBarButton-derived classes CalculateLayout() method, then all the bars exhibit the huge frame problem.

Problem 2) Problems redocking bars to the right of each other. I tried using the "fixed mode" approach, but ProfUIS _insists_ on truncating the bars. I thought these were fixed when docked? Why is ProfUIS truncating them? I want it to work like MFC, and just move to the next row down.

Problem 3) When I do #2, and then try to move a bar, it get a nasty ASSERT about "affixmentdata".

We also have some issues with toolbar paint performance, inability to override Fixed_GetRowDistance() unless we derive a new paint manager (don’t want a vertical floating toolbar with 6 pixel spacing between buttons).

I can put together a test program if you’d like.

Two more details -- on the 50 button bar with the text, if I cut down the number of buttons to like 10, then it works fine. But that is because it fits on the screen.

And when I force all the CExtBarButtons to be wide, only the toolbars that are wider than the screen get the huge floating window. The ones that are smaller than the screen work fine.

Overflow somewhere?

The behavior we want is for the 50 button bar to float into a single row horizontal bar. We’re 1/2 way there -- just have to get the minidock to resize.

Thanks

We tried to use 10 times wider toolbar buttons to repeat the problem described in your message. We added the m_ActiveSize.cx *= 10; code at the end of the CExtBarButton::CalculateLayout() virtual method in ExtToolControlBar.cpp. We found the floating toolbar or menu bar just arranges its buttons into a larger number of rows to make all its buttons visible on the active desktop area. We used SDI sample with two different toolbars in our tests. Unfortunately we were unable to reproduce the problem you described. So, your sample application would be of great help.

The problem with docking toolbars relative to each other may only appear if you forgot to call RecalcLayout() before retrieving a window rectangle of the first toolbar, which is used to dock the next toolbar next to the first. But this should cause no assertions. So, if you demonstrate this problem in your sample application or send us the source code of the main frame window of your real application, this will help us resolve the issue

We agree that the CExtPaintManager::FixedBar_GetRowDistance() method is not very convenient because there is no similar method in the CExtToolControlBar class. We can add the CExtToolControlBar::OnGetRowDistance() virtual method which will call the paint manager by default.

Thank you for spending time on these issues. I’ll try to put together a test project, but I’ve since discovered some workarounds.

My workaround for the huge floating window is to derive my own toolbar class, override _WrapToolBarH(), and at the end of that method, if it is floating and the passed in width is greater than screen X, then set the wrap flag on the buttons as to get 3 columns. Seems to work great. I think it makes more sense than having a really wide single row floating bar.

My workaround for the collapsed docked toolbars is to force multiple rows. It was trying to put them all on one row, confined by the window size, so it crunched them down to single icons with the expand down arrow button. My workaround is to add code to kick down to the next row if there isn’t room on the current row. This seems to work great too.

My workaround for the affixment ASSERT was probably not good. Again, derive a new toolbar class, give it a static int member variable, and in the ctor set the affixment weight to that variable, and then increment the variable. That way I don’t get hammered with ASSERTs about affixment weights being equal every time I try to move a docked toolbar.

Anyway I’ll try to put together a test project. One thing I could really easily do right now is sent you some screenshots of the huge floating window, and of the crunched bars.

I would like to say that, other than these minor issues, things are looking pretty good.

Thanks again.

Thank you for your comments and ideas. We will be glad to review your toolbar’s code and give comments on this issue. Of course, we would appreciate if you would send us screenshots or a project.