Zitat von Duncan Parsons <[email protected]>:
Standard way to create 'Transparent' controls is to override the paint
messages and insert the 'background' you want after inherited and before
your contained painting. You get the background from requesting a paint
from the parent of your control.
LM_ERASEBKGND
Eg in windows you would create an HDC, and send a WM_PAINT to the parent
control, then based on your own coordinates blit what you want into your
control. Delphi has some encapsulation around that (as I recall, been a
few years since I needed to do this).
Sounds complicated.
Opaque painting is in fact an optimized way of clipping and painting
parents before children.
Remove the clipping and you get transparency.
The problem is that clipping, double buffering and paint order are
deeply integrated into the widgetsets.
Now, whether all widgetsets will support this for use in Laz is another
matter - can we tell a control to paint itself to an arbitrary canvas? I
have a feeling that OSX might complain, since (from what I understand)
paint cycles are primarily OS based, and a process draw-request might be
offensive.. As for GTK.x I couldn't say.
AFAIK carbon/cocoa does not allow that.
The default gtk widget is transparent. But the LCL gtk interface
cripple this away to be Delphi compatible. One of the gtk3 features
are several improvements to render widgets to arbitrary contexts.
But that's essentially the way to do it. You _could_ do it by for going
the inherited call, and just paint onto whatever canvas you are given -
but from experience I can say that this can be unreliable: it's worth
the small overhead of getting the parent background.
Mattias
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
