TControlBar is buggy, how to unlock paint update?

[jamie]

Due to all the past complaints of Flicker, Flicker and so on, I believe it was taken too far to alleviate the issue, an issue that most likely was overstated!

If I drag and drop two TButtons into a TControlBar, the control bars do not paint unless you resize the form or the controlbar itself.
no amount of Invalidate, Repaint, Update etc will force it to paint, basically the update is locked because the size hasn't changed.

 The following is an example of a simple text program that you can create.

 2 TButtons, with Auto Drag set to true and the rest of the code you can see here.

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

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ExtCtrls, StdCtrls;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     Button1: TButton;
16.     Button2: TButton;
17.     ControlBar1: TControlBar;
18.     procedure ControlBar1DragDrop(Sender, Source: TObject; X, Y: Integer);
19.   private
20.  
21.   public
22.  
23.   end;
24.  
25. var
26.   Form1: TForm1;
27.  
28. implementation
29.  
30. {$R *.lfm}
31.  
32. { TForm1 }
33.  
34. procedure TForm1.ControlBar1DragDrop(Sender, Source: TObject; X, Y: Integer);
35. begin
36.   (Source as TWinCOntrol).Parent := nil;
37.   COntrolBar1.InsertControl(Source as TWinCOntrol,COntrolBar1.ControlCount);
38.   COntrolBar1.StickControls;//This appears not to work!
39.   Controlbar1.Width := Controlbar1.Width+1; //Must do the following to paint it
40.    ControlBar1.Width := Controlbar1.Width-1; //this is an old BUG for a few controls.
41.   {The Code presented unlocks the update so it will paint}
42.   {This is not restricted to the COntrolBar, it happens elsewhere too}
43.   {Using update, Repaint, Invalidate etc has no effect}
44. end;
45.  
46. end.
47.  
48.  
49.  

SO my question is, where is the flag I can turn off to force it to update without me doing what you see above?

[jamie]

I believe I found the issue that is causing this particular problem!

It appears that the bands only get painted when a WMSIZE message is coming, and the Paint handler is only updating the border from what I can see and maybe the background.
 
 Adding or removing child controls should be doing something to trigger a WMSIZE message or a direct call to the WMSIZE internally.

 Since the InsertControl is overriden in this control, could be a place to post a WM_SIZE message. ?

[wp]

With the following code the issue does not occur for me (Win-11, Laz/main + fpc 3.2.2). Are you sure that InsertControl does everything what SetParent does?

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

1. procedure TForm1.ControlBar1DragDrop(Sender,Source: TObject; X,Y: Integer);
2. begin
3.   (Source as TWinControl).Parent := Controlbar1;
4. end;

[jamie]

The insertCOntrol is overrided in the ControlBar and the code used in the libs indicate that.

Maybe setting the parent directly fixes it however, the fact remain those bars do not get addressed unless a WM_SIZE messge is recieved.

 Also, the InsertControl takes care of creating the Bands when inserted via the over ridden method of InsertControl

That is problem #1 which can be circumvented in code.

Problem 2:

 It does not align controls consistently. in Design time if you add a few Tbuttons to the ControlBar, they look good, but when you excute the code, some of the buttons are staggered below and some out of sight!

[wp]

Also, the InsertControl takes care of creating the Bands when inserted via the over ridden method of InsertControl

Setting a break-point in the TControlbar's InsertControl shows that it is called even when assigning the Parent directly like I showed.

It does not align controls consistently. in Design time if you add a few Tbuttons to the ControlBar, they look good, but when you excute the code, some of the buttons are staggered below and some out of sight!

This happens with both your and my methods. And  I checked Delphi: it has the same issue. The point is that the Left position of the dragged button is retained when the parent is the controlbar. When I add

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

1.   (Source as TWinControl).Left := 0;
2.   (Source as TWinControl).Top := 0;

to the OnDropDown handler the first dropped button then is at the top/left position in the controlbar; the second dropped button, however, is not positioned behind the first one, but below it (Left = 0). In Delphi, on the other hand, the second button is aligned correctly behind the first one. But changing the parent AFTER repositioning the buttons fixes the issue also for Lazarus.

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

1. procedure TForm1.ControlBar1DragDrop(Sender,Source: TObject; X,Y: Integer);
2. begin
3.   (Source as TWinControl).Top := 0;
4.   (Source as TWinControl).Left := 0;
5.   (Source as TWinControl).Parent := (Sender as TWinControl);
6. end;

[jamie]

Problem with using the Debugger and break points is that when you do that, the window gets a resize message due to you using the debugger, you can't rely on that. The use of the debugger in this way for GUI problems can be miss leading.

 Getting back to the InsertControl, there is an index that allows you to insert the control in front of others if you desire, I believe that is one of the points of using that method.

  I can do what I've done in the past and that is fixing the code on my end but every time a new release comes around, those fixes normally aren't in It so I have to do this all over again.

 My attempts of submitting patch files haven't been very successful lately since the system changed over to Git or whatever it is now.

  It looks like I may need to create my own tool menu control, this also has to be in line with Delphi to a degree or something I can use preprocessor statements to control the selection of code between the two.


P.S.

 I found if I set the TOP of each control at startup, they then move and keep in order! These are the ones placed there at design time.

 This is really strange.

 I may be able to work around with that.