TToolbar incompatible with TForm.DoubleBuffered?

Question

I am using Delphi XE3.
When I create a new VCL project and drop a TToolbar on it, everything works fine - except when I activate Form1.DoubleBuffered.
From that moment on, drawing of the toolbar is broken - in designtime, it's either black, transparent, or parts of the IDE (statusbar, toolbar, etc.) are copied into it. It changes between these options when I click on it and when I change to source code (F12) and back.
In runtime, it's always black.

With DrawingStyle=dsGradient, everything works as expected. Switching back to dsNormal breaks it again.

Deactivating Form1.DoubleBuffered repairs it.

Any hints how to work around that issue?

Graptolite

See When not to use DoubleBuffered. Workaround here is to put the TToolBar on a TPanel. – Nod

Thank you LU RD - works perfectly. If you post this as an answer, I'll mark it as solved. – Graptolite

Or you might fill the toolbar's client rectangle in the OnAdvancedCustomDraw event at the cdPrePaint drawing stage (quite a dirty workaround though). – Extrapolate

Thank you for that link, David. I don't need DoubleBuffered for deflickering VCL components, but for a TPaintBox that is drawing a chart (with user interaction like zooming and dragging). I know I could use a TBitmap (or a TImage), but as long Form.Doublebuffered works (and no other problems arise), I prefer the single click solution. – Graptolite

Doublebuffered creates lots of problems in many controls not only with TToolbar. But if you disable it you will have a lot of flicker in some areas of your program... So... choose your poison. – Billiot

Answer 1

In my opinion the solution is to set TForm.DoubleBuffered to False. Using a value of True causes all sorts of other problems. This property worked reasonably well before XP themes, but since their arrival, using TForm.DoubleBuffered has not been viable, in my view.

In addition to the problems you have encountered, I've come across lots of painting flaws when using the Windows Basic theme. I know that's not mainstream, but I happen to see that a lot with remote access. And there's more. When you double buffer a form you stop the theme animation from working. For example, a default button pulses to indicate that it is the default button.

If you get resize flickering without double buffering the form, use the ideas from my answer to another question. From the comments it seems that the flickering you wish to combat is in a paint box. I obviously don't know the details, but my experience and instincts say that you should be able to deal quite easily with that flickering at a local level. There surely should be no need for the global form wide double buffering.

Cuisse

Thank you for your hints. As I posted to your comment on my question, I'll use the TPanel solution for now - but I'll keep your remarks in mind and will definitely look into the issues you mentioned; problably I'll do what you said. Thanks again. – Graptolite

De-flickering your paint box is very easy. Double buffering the form is grossly over the top. It influences so much else. It's a global solution to a local problem. It should be avoided. – Cuisse

Yes, I can't negate what you say. I didn't know TForm.DoubleBuffered causes that much problems; I think I'll go and deactivate it everywhere I've used it until now. So thank you once again ;) – Graptolite

Answer 2

As reported in this article, When not to use DoubleBuffered, some controls like TToolBar and TRichEdit don't work well with the DoubleBuffered property set to true.

The reason be be found in documentation, TWinControl.DoubleBuffered, where some WinControls can't draw themselves on a temporary bitmap (as happens when DoubleBuffered is true).

One workaround can be to put the TToolBar on a TPanel.

Nod