Forum

Dear Support,

In a command-handler of my app I remove all buttons of my toolbars and insert some again. After that of course I invalidate them again as described in your help:

if(m_wndToolBar.IsVisible() ){
m_wndToolBar.GetParentFrame()->RecalcLayout();
m_wndToolBar.Invalidate();
m_wndToolBar.UpdateWindow();
}

But after command-handler returns, no button can be seen in the toolbar, although I can make them visible again by making the toolbar floating (also visible after docking toolbar back again). The problem might be with removing _all_ buttons, because if I don’t remove all, but leave one behind, it all works again. Could you please check this issue?

Thank you: Chris

First of all: I didn’t mention I’m using v2.52 with VS7.1

Second: I investigated a little further. It seems like my problem can be solved like this: before the updating code-segment mentioned above, I have to set the bDoRecalcLayout parameter to TRUE in the last call of either InsertButton or RemoveButton. I never set this parameter to TRUE before, thinking that later on calling m_wndToolBar.GetParentFrame()->RecalcLayout(); does the same. Was this behaviour intentional?

Chris.

If you repaint a toolbar with the Invalidate() and UpdateWindow() methods, that means you simply delivers the WM_PAINT message to the toolbar. But it does not know whether the internal _RecalcPositionsImpl() method should be invoked for recalculating all the mutual button positions. So, you can use the current solution or invoke toolbar’s CWnd::SetWindowPos() method with the SWP_FRAMECHANGED flag.

I am calling both InsertButton and RemoveButton in a loop, so I’d rather not set bDoRecalcLayout parameter to TRUE in them, making CExtToolControlBar::_RecalcLayoutImpl(); to be called a lot of times. I tried your solution, calling CWnd::SetWindowPos() with SWP_FRAMECHANGED. Since I don’t want any other parameter of SetWindowPos to be used, I used SWP_FRAMECHANGED|SWP_NOMOVE|SWP_NOSIZE|SWP_NOZORDER as nFlags. But that didn’t work either, toolbar buttons were still invisible.
So I just made a public RecalcLayout method of my CExtToolControlBar-derived class, calling the protected CExtToolControlBar::_RecalcLayoutImpl(); method in it. So now calling this RecalcLayout after my loops works perfectly, with only a little flickering. Are there any dangers of this solution?

Thank you:
Chris

We do not see anything dangerous in this solution. You can send us your project so we can suggest an absolutely flicker free solution.

The mentioned flickering affects only the icons, and only those disabled at the moment of recalculating the layout. Those icons appear as enabled for a blink, but OnUpdate... handlers turn them disabled right after. I don’t think there’s an absolutely flicker free solution for that. I can live with this blink ;) But if you have any idea of how to eliminate it, I’ll try it of course.

Thank you for all your help:
Chris.

We think you need to use pToolBar->SetReraw( FALSE ) before you change buttons and pToolBar->SetReraw( TRUE ) after that.

SetRedraw didn’t do the trick:( Right now this problem is on a lower rank in my to-do list, but later on I’ll try to make a little sample application showing the problem, and I’ll send it to you by e-mail. Thank you for all your kind help! Chris.