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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
