Recent

Author Topic: Tcontrolbar:child controls move around between Runtime, DesignTime etc.  (Read 751 times)

jamie

  • Hero Member
  • *****
  • Posts: 3526

 Trying to implement some code using the TcontrolBar has turn non prosperous.
 
  Position the control at design time as you wish but at runtime they move.

 for example
 
 Drop a TControlbar on the form, put in some buttons, lets say three of them, two vertical on the left and one on the right.

 Position them in the OI so the one's on the left are vertical and the third is sitting to the upper right corner.

 Run the code..

 the two on the left vertical will move down and slide under the border of the tcontrolbar

 now try some docking experiments, each time you drop them or move it around the controls keep moving.

 I would very much like to know without me doing some long LCL debugging how to keep them in the order I want, mainly not moving !

The only true wisdom is knowing you know nothing

jamie

  • Hero Member
  • *****
  • Posts: 3526
Since no one has replied I took a look at the source code for this control and I am surprised it is able to get out of its own way..

 I know coding is a hard job at times because I've done it for years so I am one that knows that however, after starring at it I got a headache and had to pull away from it.

 I then fired up Delphi which currently I am being forced to get acquainted with and found that it works fine there. The child controls do not reposition themselves from the design time info on startup and also stay put if you perform some Docking operations, that is moving the whole control around etc.

 I don't dare to touch much of this control since I believe it is also used in conjunction of the TCoolbar, so we don't want an upset there however, the Tcoolbar could be suffering ill side effects from this control, who knows..
The only true wisdom is knowing you know nothing

Blaazen

  • Hero Member
  • *****
  • Posts: 2918
  • POKE 54296,15
    • Eye-Candy Controls
I worked on both, TControlBar and TCoolBar, years ago. I'm pretty sure I never tested them with any docking. And yes, TCoolBar is more mature.
Lazarus 2.1.0 r63881 FPC 3.3.1 r40507 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

jamie

  • Hero Member
  • *****
  • Posts: 3526
well, I was wrong about its use..

 Apparently the TCoolBar does not use the TControlBar as the base, it uses the Ttoolbar.

so that leaves the fields wide open to fix the TControlBar then...

 But I don't want to use the CoolBar because it's over kill and has specific operations that will impede what I am doing.
The only true wisdom is knowing you know nothing

jamie

  • Hero Member
  • *****
  • Posts: 3526
Can anyone honestly say they have use the TControlBar recently ?

Its a train wreck...

 I am trying to figure out how it should work but it seems its all over the place with its positioning , sizing of the grippers etc..

  Basically it's in a unusable state.

  Sorry, that's my opinion.. It should be uninstalled from the palette , yes it's that bad.


The only true wisdom is knowing you know nothing

GetMem

  • Hero Member
  • *****
  • Posts: 3757
@jamie
Quote
Can anyone honestly say they have use the TControlBar recently ?
Its a train wreck...
I am trying to figure out how it should work but it seems its all over the place with its positioning , sizing of the grippers etc..
Basically it's in a unusable state.
Sorry, that's my opinion.. It should be uninstalled from the palette , yes it's that bad.
I have never used it. To me TControlBar looks similar to TCoolbar, each dropped control acts like a TCoolBand. Taking into account your idea from post one, I created a small demo application. It works decently in my opinion, if you keep in mind that is some kind of TToolbar. You can drag the buttons arround, it will increase the height according to the buttons position, etc. It's very similar to Lazarus IDEToolBar which is a TCoolbar.

jamie

  • Hero Member
  • *****
  • Posts: 3526
I guess u are not seeing the disaster I am seeing. If simply drop teo buttons in it chances are the first one drop out of position on app startup.
Also I see the button does stay in the boundaries of the gripper s
square,  its overlapping a button on top.
 It it a mess. This is tested in 2
0.8 and down.
The coolbae does work but a little more than I wanted.

 Like I said it should be removed because it's in unusable state from where I sit.

I am working on a suitable replacement for my needs and it looks and behaves like it should so far.
The only true wisdom is knowing you know nothing

Blaazen

  • Hero Member
  • *****
  • Posts: 2918
  • POKE 54296,15
    • Eye-Candy Controls
@ jamie: It is on Windows? Because when I test it on Qt, it basically works. I remember tḧat someone complained to TControlBar in Windows years ago but I wasn't able to reproduce in Wine so it was probably never fixed. BTW, there's no opened TControlBar issue on bugtracker.
Lazarus 2.1.0 r63881 FPC 3.3.1 r40507 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

wp

  • Hero Member
  • *****
  • Posts: 7539
Tried to reproduce GetMem's demo which works fine. I had the problem that when i add two buttons to a TControlbar and run the program, that only one is shown. After some playing around I found that I must set the Controlbar's AutoSize to true to get rid of this effect. Are you doing this, too, jamie?
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

jamie

  • Hero Member
  • *****
  • Posts: 3526
Tried to reproduce GetMem's demo which works fine. I had the problem that when i add two buttons to a TControlbar and run the program, that only one is shown. After some playing around I found that I must set the Controlbar's AutoSize to true to get rid of this effect. Are you doing this, too, jamie?

 Autosize is the only thing that brings it close to some what useable but still its messed up...

 I don't want auto size set because I want empty areas below where I can drop in more controls and give them a gripped thus being able to move them around where I want them but this just lets to control start moving child controls around in a un predictable manner.

 Also when resizing the child controls the gripper box is suppose to follow the size of the child control, it behaves in steps sizing not following the control there by leaving blank areas around it.

 If you can load up a simple test app on Delphi , just drop a Tcontrolbor on the form and add 3 Tbuttons to it.

 Set the auto Size = false; and Play with the gripper sizing.

 you are going to see a big difference in behavior, a behavior that is actually acceptable.

 It was commented about no open reports on this control, which is why I asked if anyone can honestly say they have used this control recently.

 I take it none have because they would of seen this or maybe don't dare to ask how it's suppose to work.

 This control is based from something similar back in the days of the CControlBar and I remember that one.

 The TCoolBar actually seems to do as it's design to but that control has behavior I can't deal with.. The TControlBar would be perfect for what I am doing if it worked.

 This is part of a pet project I pulled from my older Delphi files in the early years and that control there still basically works the same way the latest Delphi does.


The only true wisdom is knowing you know nothing

GetMem

  • Hero Member
  • *****
  • Posts: 3757
@jamie
Well in this case, developing your own control is the best solution.

 

TinyPortal © 2005-2018