[Lazarus] nonlcl basic issue: is codetools LCL dependent?

[Giuliano Colla]

Il 27/06/2014 23:34, Juha Manninen ha scritto:
> You seem to have unusual GUIs. Still, I have a feeling you do 
> something wrong when creating controls in code.
> Setting the position, size or anchors at runtime work well.
> Gtk2 may have some Z-order issues, QT is better.
Well, I may give you a small example. Two buttons, side by side. The 
first one has AutoSize set, to fit a text which must be determined at 
creation time. The next should go some ten pixels from the right edge of 
the first, and stay there even if the first is made invisible.

Kylix code:
Create the first button, then create the second. Set its Left property 
to Left_of_the_first+Width_of_the_first+required spacing. You're done, 
it works.

Lazarus code:
Just take Kylix code. The second button is partly over the first one.
You mumble a bit and understand that the Width you get isn't the actual 
Width of the button after AutoSizing, but just the default Button Width. 
Then you add some code, i.e. you calculate the TextExtent on the canvas 
of the first Button to evaluate the actual Width, add the few extra 
pixels for the button border, use this value, and finally it works.
(I can't anchor the second Button to the first, because if the first 
becomes invisible, the second is moved from his position, which is not 
acceptable).

> I did not use a background bitmap but it should be doable, too.
>
Of course is doable. But how many kludges are required to ensure that at 
each repaint the Z-Order is properly respected, and that you don't have 
controls below the bitmap, or empty bitmap areas? I've done it once, and 
when I got tired of fighting there were still some detail which should 
have been adjusted.
> If you ask specific questions in a new mail thread with example code 
> snippets, I am sure people here will find solutions.
>
I don't share your confidence. Many problems are related to the way the 
widgetset send signals back: if signals are missing or wrong, there's 
little that developers can do. The intricacies of Interfaces make it 
very difficult to debug, or simply to locate the problem.

I have raised a problem quite some time ago: (as of Lazarus 1.0.8): If 
you move another window over a Group Box, not all controls are repainted 
properly when they're uncovered: the Group Box Title, Speed Buttons and 
Labels aren't repainted, or just partly repainted. Buttons and 
BitButtons are unaffected.
As of Lazarus 1.3 rev 45619 the problem is still there. I still compile 
an application where this problem is an issue because the affecting 
window is just the dropdown of a ComboBox, with a legacy Lazarus 0.9.28 
(or something around) which doesn't show the problem.

But a new similar problem which wasn't in 1.0.8 has popped up in the 
meantime: if you have a SpeedButton on a Panel, when you pass the mouse 
over it, and the control is highlighted, some surrounding controls are 
partly erased. e.g. TLabel is affected, TStaticText is not. You must add 
an OnMouseEnter and OnMouseLeave event to your SpeedButton, which 
triggers a repaint of the Panel to restore all controls.

Graeme Geldenhuys who had problems of the same sort ended up designing 
his own widgetset. I'm more modest, and I look to a design mediator.

Giuliano