[Solved] Trackbar flickering

[Joanna]

Hi everyone
I have a ttrackbar control inside of a panel. When I resize it it flickers despite of the fact that I have set doublebuffered to true for both the trackbar and panel.

I searched the forums for previous thread about this and it seemed that it had been solved by adding csParentBackground to the control style. It didn't seem to stop flickering for me and on closer inspection i saw this.

csParentBackground = CSPARENTBACKGROUND

enum TControlStyleType.csParentBackground

C:\lazarus\lcl\controls.pp(257,5)

Description

[not implemented]

tells WinXP to paint the theme background of parent on controls background

 (Source)

Package

LCLBase

Does anyone have any other ideas on how to reduce trackball flickering ? it only gets worse when the panel with trackbar is nested inside of another control.

im using
Lazarus 2.0.12 r64642 FPC 3.2.0 x86_64-win64-win32/win64
with windows 7

[440bx]

Question: is the location of the trackbar constant ?  IOW, when resizing, does the trackbar need to move or stay in the same place ?

[Joanna]

The trackbar will stretch to fill its parent and as it stretches  the little notches under it become further apart.
So if I am resizing from right  the left side of trackball will not move

[wp]

No flickering here: Win11, Laz/main+FPC 3.2.2 (32 bit) or Laz 2.0.12/FPC 3.2.0 (32bit). But strong flicker in a VM with Win 7, it even flickers when the form size changes but the trackbar is not anchored/aligned and remains unchanged - I don't think that there's much you can do...

[440bx]

Disclaimer: I don't know how to do this in the LCL...

in a normal window procedure I'd set the result of processing the WM_ERASEBKGND  to a non-zero value (usually 1), telling Windows that the background has been erased.  Erasing the background is usually the source of flicker - since you have enabled double buffered painting it should be ok to lie about having erased the background - there is at least a chance this will eliminate the flicker.  I'd do that for _both_, the panel and the trackbar.

Just in case, WM_ERASEBKGND is documented at:
https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-erasebkgnd

HTH.

[Joanna]

Thanks for the answers.
I haven’t tried this on other operating systems yet hopefully it will work better. So I don’t want any windows dependencies.

The thing that concerns me more is
enum TControlStyleType.csParentBackground not being implemented. Why is it not implemented ? It was implemented for windows xp?

[d7_2_laz]

->  @440bx, fyi (->  as it’s Windows): I had sometimes such situation where I noticed that it had not much effect to ‘return 1’ (for True). Maybe because the control’s background itself already had an unwanted color. What did I want to do instead? To enforce a very early repaint in the desired color. Especially I had that when working with the dark mode: where I saw for some controls white flashes at resize (wm_maximize)  or at program’s start.
For the scenario: a Form, and an already existing component in it, i give a simple example snippet that might be easily adapted for other controls and colors.

Code: Pascal  [Select][+][-]

1. unit MainUnit;
2. …..
3. type
4.  
5.   TSplitter = class(ExtCtrls.TSplitter)
6.     procedure WMEraseBkgnd(var Message: TLMEraseBkgnd); message LM_ERASEBKGND;
7. …..
8.  
9. implementation
10.  
11. …..
12. procedure TSplitter.WMEraseBkgnd(var Message: TLMEraseBkgnd);
13. var vRect : TRect;
14. begin
15.   if Not IsDarkModeEnabled then
16.      exit;  // No need here in light mode
17.   if Message.DC = 0 then Exit;
18.   Brush.Color := $00353535;
19.   vRect := Rect(0, 0, Width, Height);
20.   FillRect(Message.DC, vRect, Brush.Reference.Handle);
21. end;

[Joanna]

Another thing I forgot to mention is that the colors in my controls are not defined by windows color themes, I choose them from inside program.
Sometimes when the trackbar is nested more it will start to show as a black rectangle while resizing. {I use dark theme in windows }

d7_2_laz, how is procedure WMEraseBkgnd called? I noticed that it isn’t overriding ancestor method if there is any.
 What if parent.color was substituted for Brush.Color := $00353535;?

[KodeZwerg]

how is procedure WMEraseBkgnd called?

You do not "call" it at all.

WM = Window Message
EraseBkgnd = the Identifier

So whenever the Window Message for EraseBkgnd flies over your TSplitter object, it will be executed automagical and overrides the original behavior.

[Joanna]

Identifier not found TLMEraseBkgnd
Does anyone know which unit has TLMEraseBkgnd?

[d7_2_laz]

d7_2_laz, how is procedure WMEraseBkgnd called? I noticed that it isn’t overriding ancestor method if there is any.
 What if parent.color was substituted for Brush.Color := $00353535;?

I think it’s called by one ancestor of the control, here probably (without having debugged) controls.pp  (see image).
And it will be called, as KodeZwreg says, 'automagical' by intercepting the windows message loop by the anchestor. You simply hook into this message for to do something within.
But - as you suspected - it probably Windows-specific, don't know if there are equivalents on other OSses.

For the second question: you mean: substitute the hard coded element by any variable, eg. parent.color? Yes, of course, the essential element is only that the “unwanted color” doesn’t stay visible .. and visible .. and visible .. until the painting will come into effect. But will be applied as early as possible. I had very good results by that (need to add that the dark theme here is by metadarkstyle component).

[Joanna]

Identifier not found for isdarkmodeenabled and fillrect which units am I missing?

[d7_2_laz]

No no, as said this dark mode thing was only one use case example where some effects were particularly noticeable.
Here, “IsDarkModeEnabled” was from the metadarkstyle package; without this package, it should be removed of course.

"FillRect" ->  from unit Windows, OS-specific too.

[Joanna]

Code: Pascal  [Select][+][-]

1. PROCEDURE TMY_TRACKBAR.WMERASEBKGND( VAR MESSAGE: TLMERASEBKGND) ;
2.            var vRect : TRect;
3. begin
4.   //if Not IsDarkModeEnabled then
5.   //   exit;  // No need here in light mode
6.   if Message.DC = 0
7.      then Exit;
8.   Brush.Color := Parent.Color;   //       $00353535;
9.   vRect := Rect(0, 0, Width, Height);
10.   FillRect(Message.DC, vRect, Brush.Reference.Handle);
11.  END;

it fails on line where vrect is assigned
TRACKBARS_UNIT_2024.pas(179,18) Fatal: Syntax error, ")" expected but "," found

[d7_2_laz]

it fails on line where vrect is assigned

Oh, I remember such trap .. has something to do with the order of units within the use clause (there might be different TRect definitions around).
Try with direct assignment, eg. vrect.Left:=0;  vrect.Top:=0;   etc,