TCoolBar

[JuhaManninen]

Actually tcontrolbar was in delphi long before the TCoolbar component was introduced and I think they were forced in to TCoolBar because the look and feel wasn't as hip and trendy as the latest and greatest from MS at that time when IE5 became the standard in 90% of windows installation some one implemented TCoolBar.

Wow, I didn't know that!
CoolBar seems to be even more buggy than ControlBar, based on complaints found by a Google search.
But no worries, the LCL versions of those components will be perfect when they are ready (who knows when that is...).

In any case LCL has its own little quirks take for instance the resize mess and the endless loops you end up with, the moment you try to re size your own internal components. I still haven't rapt my head around that piece of code.

Yes, the layout system in LCL is different, but IMO it is better.
LCL automatically adjusts sizes until all has settled. VCL does not and thus it does not loop.

It is quite well explained here:
 http://wiki.lazarus.freepascal.org/Autosize_/_Layout#Difference_to_Delphi

I must also wrap my head around alignment and autosize again for the loop Avishai found.
I think I must override CalculatePreferredSize, too.

Juha

[taazz]

Warning what follows is personal opinion so take it with a grain of salt.

Actually I disagree. Although delphi does not try to enforce any kind of layout it gives you the tools to do that your self and it is quite simple to use them in your code to do anything you like. What ever tools are given to you they work as advertised eg anchors. Simplistic? Yes a bit over engineered? Probably, non the less it works and it works well. I can't say the same think for the lcl layout. The only think I managed to use with out problems is the alignment (alRight, alClient etc) and the border spacing. Everything else has produced problems for me, anchors where extremely nasty because they did not raise any error they simple did not work when they were set from a constructor.

My worst irritation is the fact that the components call the parent's resize method inside their resize method, a practice I find problematic in most cases and I haven't seen any code that uses such concepts that do not creates more problems than it solves yet.

If you must call it then do it asynchronously make sure it is called after the current resize has finished its job, that of course would not solve the current looping problem.

[Blaazen]

In any case LCL has its own little quirks take for instance the resize mess and the endless loops you end up with.

I have sometimes endless loops when I set anchors wrongly. Sometimes it shows message window (This will create circular dependency [Ignore] [Cancel]), sometimes it freezes for a while.

[JuhaManninen]

Yes, I realize it can cause unnecessary problems when using a Delphi compatible layout.
However it is needed for the more advanced layouts that LCL supports as the controls can be anchored to each other in different ways.
That is my understanding anyway. Mattias could explain it better.

[Edit]
I had to learn quite much about those layout algorithms to make CoolBar.AutoSize work.
A label used for a Text property always created a ChangeBounds loop error, only because I set its Left and Top properties.
I experimented for many hours and finally had to ask Mattias. Only the label's Align must be set to alCustom instead of alNone. Then it started to work.

CoolBar was a difficult case because it implements its own layout by overriding AlignControls and CalculatePreferredSize (for AutoSize).

I could have saved many hours by asking Mattias at once, but I feel stupid always asking him like a child.
Anyway, now I know more. Next component will be easier.

Juha

[JuhaManninen]

TControl.ChangeBounds loop detected Edit1:TEdit Left=53, Top=3, Widrh=409, Height=24 NewLeft=53, NewTop=-2, NewWidth=409, NewHeight=24

All ChangeBounds loops are now fixed. It was a tough one.
BiDiMode works, too.
There are some minor layout issues left and the "Break" feature is not implemented at all.

Juha

[Blaazen]

A little off-topic for Juha.
In past, I reported this: http://bugs.freepascal.org/view.php?id=23029
You replied there that the control will be redesigned. I am curious how.
Reason is that I designed control (CustomSpinEdit - see image) similar to TEditButton, i.e. basic component is TCustomEdit and buttons (TGraphicControl) are sticked to it.
Before, I also tried another design, the basic control was TWinControl (as a non-visual container) and both TCustomEdit and side-buttons was placed on it.
It worked but it had a problem with focus. AFAIR if I switched focus (with Tab), the focus was not always given correctly to Edit. Also, TWinControl only as a container is an overhead. Therefore I left that design.
Advantage of the previous design was mainly better anchoring and easier usage for a grid cell editor.

So I would like to know if it is already decided how the control will be redesigned.
Thanks.

[JuhaManninen]

A little off-topic for Juha.
In past, I reported this: http://bugs.freepascal.org/view.php?id=23029
You replied there that the control will be redesigned. I am curious how.
Reason is that I designed control (CustomSpinEdit - see image) similar to TEditButton, i.e. basic component is TCustomEdit and buttons (TGraphicControl) are sticked to it.
...

It has not been discussed for some time, but the consensus is that it should be changed.
In earlier discussions the idea was to tweak the bounds etc. at widgetset level which may be difficult in some cases and requires more maintenance. In the Mantis issue #12155, related to your issue, Mattias however writes he made a proof of concept version by using an edit and a button on a panel. He has put it to examples/groupedcontrols.
Please take a look.

May I suggest that you make a refined version of that control. First the validity of this design must be confirmed on mailing list. Then I can help with committing the code. First it can be inside {$IFDEF NewEditButton} and becomes default only after it is well tested. It would make its way to Lazarus 1.2 which is not scheduled yet.
What do you say?

Later you can use the same design for your CustomSpinEdit (which you should rename because LCL already has one).
The exact same code may not be reusable for your 2-button design.

Juha

[Blaazen]

Thanks for reply.

@Later you can use the same design for your CustomSpinEdit (which you should rename because LCL already has one).
The exact same code may not be reusable for your 2-button design.

It already has other name, I used CustomSpinEdit only now to better describe what it is.
In fact, it's not 2-button design, it can have 1-9 buttons but it is everything only one TGraphicControl.


I saw the old bugreport, I also started the demo. Some things has to be finished, vertical resizing for example.

Anyway, it is interesting. Don't you know why Mattias decided to use TCustomPanel (which is TCustomControl) instead of TWinControl (as I did)?
I chose the second because it is more lightweight.

Only note: if someone else want to test the component, you need to have installed "runtimetypeinfo" package.

EDIT:
@ May I suggest that you make a refined version of that control. First the validity of this design must be confirmed on mailing list. Then I can help with committing the code. First it can be inside {$IFDEF NewEditButton} and becomes default only after it is well tested. It would make its way to Lazarus 1.2 which is not scheduled yet.
What do you say?

OK. Since many is already done, I'll try to finish missing pieces and test in Qt4 and GTK2. As a stand-alone component, anchoring and as a grid cell editor.

[JuhaManninen]

Anyway, it is interesting. Don't you know why Mattias decided to use TCustomPanel (which is TCustomControl) instead of TWinControl (as I did)?

I guess Panel provides some functionality that TWinControl does not provide. Don't know.

OK. Since many is already done, I'll try to finish missing pieces and test in Qt4 and GTK2. As a stand-alone component, anchoring and as a grid cell editor.

Great. Could you also write to mailing list to confirm this plan is OK. Many developers don't follow the forum actively.

Juha

[taazz]

Stupid question alert.
Where can I get the tcoolbar and tcontrolbar components?

[Blaazen]

TControlBar is on "Additional" and TCoolBar is on "Common Controls". AFAIK TCoolBar.Bands does not work properly yet (they are not Delphi compatible).
Of course, in Lazarus trunk.

[taazz]

thank you Blaazen.

[JuhaManninen]

TControlBar is on "Additional" and TCoolBar is on "Common Controls".

The tabs are the same as in Delphi. It is a historical remain as TCoolBar used to be a COM Windows control.
In LCL it is built from other widget primitives. It should be in the same tab with TControlBar.

AFAIK TCoolBar.Bands does not work properly yet (they are not Delphi compatible).

Yes, the "Break" property does not work, neither does dragging the bands at run time.
CoolBar.Bitmap and CoolBar.Images have no effect.

All properties needed for Delphi conversion are there and the implemented features work well.
In parts it works better than the Delphi's COM control. VCL communicated with it using messages and it never worked well. You can move the controls out of their bands for example. In LCL's CoolBar you cannot do that.