Hi,

I have a question / feature request for a TCoolBar at designtime and Lazarus IDE.

If I assign a control (e.g. TPanel) to a TCoolBar, a TCoolBand according to the dimensions of TPanels is created. Thats fine! If I change now the dimension of that control (at designtime), at runtime, the width of the TCoolBand got the width of the TCoolBand and the height got the height of the control.

There are two features, what would be nice to have:

If the height of a TCoolBand child control is changed, the IDE should show the identical height at designtime, the width of a TCoolBand child control is changed, the width of the TCoolBand should also be changed.

As a workaround, you can move the control from the TCoolBand to a other parent, delete the TCoolBand and move the control back to the TCoolBar. Then a TCoolBand with the correct dimensions is created.

PS: I know, that the width can be changed by the user at runtime, so that a differentiation of designtime and runtime has to be made.

Hope, you understand my poor English.

Michael

Hi,
?
developing TCoolBar wasn't easy, one must deal with LCL austosizing mechanism, which is very sophisticated. I know that in design-time is not band-height recalculated immediately. The reason is mainly I wanted to do CoolBar efficient and avoid redundant recalculation (LCL triggers many resize events). ?
I understand you, it would be nice to have it perfect (panel will resize band and band will resize panel). However, I wouldn't like to make big changes to design of TCoolBar, I happy it works and is stable :-). ?
BTW did you try TControlBar? Maybe it will suite you better. ?
______________________________________________________________

Hi,

I have a question / feature request for a TCoolBar at designtime and Lazarus IDE.

If I assign a control (e.g. TPanel) to a TCoolBar, a TCoolBand according to the dimensions of TPanels is created. Thats fine! If I change now the dimension of that control (at designtime), at runtime, the width of the TCoolBand got the width of the TCoolBand and the height got the height of the control.

There are two features, what would be nice to have:

If the height of a TCoolBand child control is changed, the IDE should show the identical height at designtime, the width of a TCoolBand child control is changed, the width of the TCoolBand should also be changed.

As a workaround, you can move the control from the TCoolBand to a other parent, delete the TCoolBand and move the control back to the TCoolBar. Then a TCoolBand with the correct dimensions is created.

PS: I know, that the width can be changed by the user at runtime, so that a differentiation of designtime and runtime has to be made.

Hope, you understand my poor English.

Michael

I'm happy, that I can use Lazarus with its LCL :))

My request is more to see as a nice to have for the continuity of the Lazarus - RAD.
Maybe you or someone else has to made some changes of that component, so this request can flow into it?!

BTW did you try TControlBar? Maybe it will suite you better.

I've tried the TControlBar (thank you for that hint), but there are also some unwanted bevaviors (like moving a childcontrol upper to top of 0, moves the other controls down). I will see, what the better choice would be.

Thank you, for sharing your component.

Best regards

Michael

En Mon, 11 May 2015 09:18:01 -0500, Vojt?ch ?ih?k
escribi?:

Any change that TCtrlBands can be re-implemented to not use generics?, while they apparently work fine on FPC trunk, they are not guaranteed to work on FPC 2.6.X. (specially advanced features like the one in r 45860) and 1.4 was apparently released with this changes.

In fact recompiling 1.4 on Mac using 2.6.X failed here :(.

Jesus Reyes A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150511/b0ac1ba1/attachment.html>

Now you surprised me. I completely forgot I used generics, I had to look to old sources because I wasn't sure whether it came from me or from someone else. ?
Anyway, FPC 2.6.4 is not able to compile it? You are the first who say it. ?
I guess replacing generics with TFPList shouldn't be difficult. ?
V.

En Mon, 11 May 2015 15:23:55 -0500, Vojt?ch ?ih?k
escribi?:

Yes I'm sure.
I'm also surprised, seems that nobody noticed.
In reality, I should have tested before but the fact that it worked on every other OS with 2.6.X is a little confusing and unexpected, maybe that is why nobody noticed in the RC's series.

...
Compiling buttonpanel.pas
Compiling extctrls.pp
Compiling popupnotifier.pas
Assembling (pipe) units/i386-darwin/popupnotifier.s extctrls.pp(1251,58) Error: Illegal expression
extctrls.pp(1251,58) Error: Error in type definition extctrls.pp(1251,58) Fatal: Syntax error, ">" expected but "" found Fatal: Compilation aborted
make[1]: *** [alllclunits.ppu] Error 1
make: *** [lazbuild] Error 2

And I can reproduce it with the attached file. The same compiles fine under Linux with fpc 2.6.X
But anyway, Sven has confirmed that 2.6.X is not guaranteed to work with all generics features, specially
like the one tested here.

$ /Users/prog/fpcbin32_265/bin/fpc test1.pas
Free Pascal Compiler version 2.6.5 [2015/05/07] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Darwin for i386
Compiling test1.pas
test1.pas(9,50) Error: Illegal expression
test1.pas(9,50) Error: Error in type definition
test1.pas(9,50) Fatal: Syntax error, ">" expected but "" found Fatal: Compilation aborted

Jesus Reyes A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150511/9f25023b/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.pas
Type: application/octet-stream
Size: 217 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150511/9f25023b/attachment-0001.obj>

Jesus Reyes wrote

Any change that TCtrlBands can be re-implemented to not use generics?, while they apparently work fine on FPC trunk, they are not guaranteed to work on FPC 2.6.X. (specially advanced features like the one in r 45860) and 1.4 was apparently released with this changes.

You surprise me, too.
The basic generics containers and the fgl unit has worked well since FPC 2.6.0. I have used both list and map generics containers already a long time and nobody complained.
The patch for r45860 was from Vojteck and committed by me. It uses TFPGObjectList which works well.

In fact recompiling 1.4 on Mac using 2.6.X failed here :(.

Do you mean generics on Mac are broken? Strange. It does not sound like a platform dependent feature.

Juha

Why did the problem come up now? As I wrote I have used generics in many places for years. For example in component palette interface code a generics map made the code much simpler. I don't want to change it to something complex with typecasts.

Juha

En Mon, 11 May 2015 16:10:06 -0500, Juha Manninen
escribi?:

TBH, I don't know if they are "completly" broken, I expressed my surprise too that it worked on other OS, and I don't have any other information apart from Sven word that 2.6.X is not guaranteed to work with all generics features, specially the one mentioned here.

Jesus Reyes A.

Jesus Reyes wrote

TBH, I don't know if they are "completly" broken,

One more thought: There is an installation package for Mac OSX, built by Mattias. He was able to compile generics on Mac. Can it depend on compiler options?

Juha

En Mon, 11 May 2015 16:18:18 -0500, Juha Manninen
escribi?:

I'm sorry to be the killjoy, but what should one do?, remain silent? :)

As I said, everything else may be working fine and some advanced features are the only affected, what is OK and what is not or what is advanced and what is not is something to be tested or read somewhere if that is documented.

As I detected the problem in my PC, I offer my help to test anything you have in mind :)

Jesus Reyes A.

En Mon, 11 May 2015 16:25:50 -0500, Juha Manninen
escribi?:

It could be, I will test and comment back later.

Jesus Reyes A.

En Mon, 11 May 2015 16:25:50 -0500, Juha Manninen
escribi?:

I tried with the released FPC version 2.6.4 and it works :P So it must be some flag that makes the difference.

The question now is if one should trust 2.6.4 when compiling generics code. IMO It is still confusing ... to use or not use...

At least the weird situation of how was possible to have a release with this
compiler and the current code in Lazarus is solved.

Jesus Reyes A.

En Mon, 11 May 2015 16:25:50 -0500, Juha Manninen
escribi?:

I tried with the released version and it works
So it must be some flag that makes the difference.

The question now is if one should trust 2.6.4 when compiling generics code. IMO It is still confusing ... to use or not use...

At least the weird situation of how was possible to have a release with this
compiler and the current code in Lazarus is solved.

Jesus Reyes A.

Jesus Reyes wrote

... Sven word that 2.6.X is not guaranteed to work with all generics features, specially the one mentioned here.

Sven's comments were about features but not about compilation problems. I still wonder what can prevent the compilation of generics on one platform. Now I remember somebody had a similar problem but the reason was never solved then. I think the person started to use FPC trunk. Ideas anybody?

Juha