Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-12

csOpaque seems to be broken in 0.9.29

34 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

What am I doing wrong, or is this another LCL bug? FMyContainer, FLabel and FButton are private field variables of TForm1. I create the three is a TCustomControl descendant that has [csOpaque] excluded from ControlStyle because I want the container component to be transparent. Yet at runtime, the component is NOT transparent.

I am painting a tiled image directly on the Canvas of TForm1, so I should be able to see the background image thru my custom container, but I can't.

Screenshot-1.png = The form with a tiled background image. Screenshot-2.png = The same form as above, but with my three runtime created components added. My custom container seems to be ignoring the csOpaque style.

Below is the complete code for Unit1.pas

-------------------------------------------------------------
unit Unit1;
{$mode objfpc}{$H+}
interface

uses
Classes, SysUtils, FileUtil, LResources, Forms, Controls, Graphics,

  Dialogs, ExtCtrls, StdCtrls;
type
  TMyContainer = class(TCustomControl)
  public
    constructor Create(AOwner: TComponent); override;
  end;
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormPaint(Sender: TObject);
  private
    FMyContainer: TMyContainer;
    FLabel: TLabel;
    FButton: TButton;
  public
    { public declarations }
  end;
var
  Form1: TForm1;
implementation

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
  FMyContainer := TMyContainer.Create(self);
  FMyContainer.Parent := self;
  FMyContainer.Align := alClient;
  FLabel := TLabel.Create(FMyContainer);
  with FLabel do
  begin
    Parent := FMyContainer;
    Top := 10;
    left := 20;
    AutoSize := True;
    Caption := 'we are in a custom transparent container';
  end;
  FButton := TButton.Create(FMyContainer);
  with FButton do
  begin
    Parent := FMyContainer;
    Top := 10;
    Left := 200;
    Caption := 'Click me';
  end;
end;
procedure TForm1.FormPaint(Sender: TObject);
var
  x, y: Integer;
  MyBmp: TPixmap;
begin
  MyBmp := TPixmap.Create;
  try
    MyBmp.LoadFromFile('./login-bckgnd.xpm');
    for x := 0 to (Width div MyBmp.Width) do
      for y := 0 to (Height div MyBmp.Height) do
        Canvas.Draw(x * MyBmp.Width, y * MyBmp.Height, MyBmp);
  finally
    MyBmp.Free;
  end;
end;

{ TMyContainer }

constructor TMyContainer.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  // Do not include [csOpaque] because we want a transparent widget.
  ControlStyle := [csAcceptsControls, csNoFocus];
end;
initialization
  {$I Unit1.lrs}
end.

-------------------------------------------------------------

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-1.png Type: image/png Size: 4198 bytes Desc: not available URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091222/a9ec51c9/attachment-0002.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-2.png Type: image/png Size: 2901 bytes Desc: not available URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091222/a9ec51c9/attachment-0003.png>

Reply by email

Paul Ishenin
to Graeme Geldenhuys
Graeme Geldenhuys wrote 8 lines
What am I doing wrong, or is this another LCL bug? FMyContainer, FLabel and FButton are private field variables of TForm1. I create the three components at runtime. FMyContainer is a TCustomControl descendant that has [csOpaque] excluded from ControlStyle because I want the container component to be transparent. Yet at runtime, the component is NOT transparent.

csOpaque is a hint which component gives to lcl whether it fully draws itself or not. It does not mean that component should be drawn transparently. Moreover it can't work for TWinControl which has a window
- HWND or GdkWindow since that windows are not transparent.

Best regards,
Paul Ishenin.

Reply by email

Graeme Geldenhuys
to Paul Ishenin
Paul Ishenin wrote
> csOpaque is a hint which component gives to lcl whether it fully draws itself or not. It does not mean that component should be drawn transparently.

To be fair, I did try and find help on csOpaque, but there was none. I then searched the LCL and found the following code with comment. I assumed from that, that csOpaque means the component will be transparent.

----------------------------------
constructor TCustomPanel.Create(TheOwner : TComponent);
begin
  inherited Create (TheOwner);
  FCompStyle:= csPanel;
  ControlStyle := ControlStyle + [csAcceptsControls, csCaptureMouse,
    csClickEvents, csSetCaption, csDoubleClicks, csReplicatable,
    csNoFocus]
    - [csOpaque]; // we need the default background
...
----------------------------------
Moreover it can't work for TWinControl which has a window - HWND or GdkWindow since that windows are not transparent.

So how else would you create a transparent container component in LCL?

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Hans-Peter Diettrich
to Graeme Geldenhuys: What am I doing wrong, or is this another LCL bug? FMyContainer, FLabel and FButton are…
I am painting a tiled image directly on the Canvas of TForm1, so I should be able to see the background image thru my custom container, but I can't.

You may have to exclude ClipChildren when painting. The result can be somewhat inpredictable, when you mix direct paints with components painting themselves. I'd suggest to draw the background in WM_ERASE, or to use a background image.

DoDi

Reply by email

Graeme Geldenhuys
to Paul Ishenin
Paul Ishenin wrote
> No idea. TControl can be transparent but not TWinControl. But TControl can't contain controls.

So that would also mean creating a Layout Manager (like Java) and being usable through the Form Designer would be impossible with LCL. :-(

OK, one less thing on my LCL todo list.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Hans-Peter Diettrich: You may have to exclude ClipChildren when painting. The result can be somewhat…
Hans-Peter Diettrich wrote
You may have to exclude ClipChildren when painting. The result can be somewhat inpredictable, when you mix direct paints with components painting themselves. I'd suggest to draw the background in WM_ERASE,

It was the quickest way to test if my component was truly transparent. I didn't want to use a solid color because the child could easily use the Parent.Color to paint it's own background.

or to use a background image.

TForm doesn't have a BackgroundImage or Image or Picture property. Though that would be truly useful.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Paul Ishenin: No idea. TControl can be transparent but not TWinControl. But TControl can't contain…
Paul Ishenin wrote 5 lines
Graeme Geldenhuys wrote: > So how else would you create a transparent container component in LCL? > No idea. TControl can be transparent but not TWinControl. But TControl can't contain controls.

I did some Google'ing. At least under XLib, it is possible. Run 'xeyes'. :-) xeyes uses the XShapeCombineMask API.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Mattias Gärtner
to Graeme Geldenhuys: To be fair, I did try and find help on csOpaque, but there was none. I then searched the…

Zitat von Graeme Geldenhuys :

Show quoted text 10 lines
Paul Ishenin wrote: >> > csOpaque is a hint which component gives to lcl whether it fully draws > itself or not. It does not mean that component should be drawn > transparently. To be fair, I did try and find help on csOpaque, but there was none. I then searched the LCL and found the following code with comment. I assumed from that, that csOpaque means the component will be transparent.

csOpaque:
- the control is treated as transparent
- but it does not make a control transparent

csOpaque is used by the LCL when clipping and mouse clicks.

Most LCL controls are not transparent and there is no flag to make them transparent.

You can create transparent controls even TWinControls with childs, but afaik nobody has yet created such a widget. And I guess you can only get limited transparency. The easiest is to just paint the parent background.

Mattias

Reply by email

Graeme Geldenhuys
to Mattias Gärtner
Mattias G?rtner wrote
?

Layout Manager acting as a "panel" and contains components that it manages. Many layout managers act like this, but you wouldn't want the layout manager component to do any painting though.

But yes I can image that you could have a non-visual layout manager component that manages any visual components on a form - without acting as a parent to any of those components.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Graeme Geldenhuys: I did some Google'ing. At least under XLib, it is possible. Run 'xeyes'. :-) xeyes uses…
Graeme Geldenhuys wrote
I did some Google'ing. At least under XLib, it is possible. Run 'xeyes'. :-) xeyes uses the XShapeCombineMask API.

That would only work as 100% or 0% transparent - no opacity though.

For opacity you could piggy-back on the compiz window managers in X11. For GTK2 you would use the following, which could be applied to any window with a handle (as far as I understand).

http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#gdk-window-set-opacity

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Mattias Gärtner: Zitat von Graeme Geldenhuys : csOpaque: - the control is treated as transparent - but it…
Mattias G?rtner wrote
csOpaque: - the control is treated as transparent - but it does not make a control transparent

This makes no sense. :-) It's told to be transparent but isn't really transparent because it still paints the background with clBtnFace.

csOpaque is then probably not the best chosen name for what LCL uses it for.

get limited transparency. The easiest is to just paint the parent background.

True, and this is what I do in fpGUI too.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Mattias Gärtner
to Graeme Geldenhuys: Layout Manager acting as a "panel" and contains components that it manages. Many layout…

Zitat von Graeme Geldenhuys :

Show quoted text 11 lines
Mattias G?rtner wrote: > > ? Layout Manager acting as a "panel" and contains components that it manages. Many layout managers act like this, but you wouldn't want the layout manager component to do any painting though. But yes I can image that you could have a non-visual layout manager component that manages any visual components on a form - without acting as a parent to any of those components.

Both are possible.

Mattias

Reply by email

Mattias Gärtner
to Graeme Geldenhuys: This makes no sense. :-) It's told to be transparent but isn't really transparent…

Zitat von Graeme Geldenhuys :

Show quoted text 8 lines
Mattias G?rtner wrote: > > csOpaque: > - the control is treated as transparent > - but it does not make a control transparent This makes no sense. :-) It's told to be transparent but isn't really transparent because it still paints the background with clBtnFace.

I will try again with other words:
Let's assume you create a non rectangular control. Then you must tell this the LCL by removing csOpaque. Normally when the user clicks with the mouse on a pixel inside the rectangular area of a control the LCL will send the mouse event to this control. Without csOpaque it must change this check.
Same when clipping child controls.

Removing csOpaque is not enough. You must override several methods to give this sense. For example not erasing the whole background and hittest.
There are many meanings of "transparent". But there is only one meaning of csOpaque. I guess, that's why Delphi called it this way.

csOpaque is then probably not the best chosen name for what LCL uses it for.

AFAIK it is delphi compatible.

> get limited transparency. The easiest is to just paint the parent > background. True, and this is what I do in fpGUI too.

Mattias

Reply by email

Zaher Dirkey
to Mattias Gärtner

2009/12/22 Mattias G?rtner :

Show quoted text 17 lines
Zitat von Graeme Geldenhuys : > Mattias G?rtner wrote: >> >> csOpaque: >> - the control is treated as transparent >> - but it does not make a control transparent > > This makes no sense. ?:-) ?It's told to be transparent but isn't really > transparent because it still paints the background with clBtnFace. I will try again with other words: Let's assume you create a non rectangular control. Then you must tell this the LCL by removing csOpaque. Normally when the user clicks with the mouse on a pixel inside the rectangular area of a control the LCL will send the mouse event to this control. Without csOpaque it must change this check. Same when clipping child controls.

You need a new control TLayout derived from TGraphicControl but have new component state csSomthing to bypass mouse action at runtime and leave it other controls, but the real problem it must have child controls and that need hard coding make many new bugs.

http://www.lazarus.freepascal.org/index.php/topic,4820.0.html

Zaher Dirkey

Reply by email

Mattias Gärtner
to Zaher Dirkey

Zitat von Zaher Dirkey :

Show quoted text 25 lines
2009/12/22 Mattias G?rtner : > Zitat von Graeme Geldenhuys : > >> Mattias G?rtner wrote: >>> >>> csOpaque: >>> - the control is treated as transparent >>> - but it does not make a control transparent >> >> This makes no sense. ?:-) ?It's told to be transparent but isn't really >> transparent because it still paints the background with clBtnFace. > > I will try again with other words: > Let's assume you create a non rectangular control. Then you must tell this > the LCL by removing csOpaque. Normally when the user clicks with the mouse > on a pixel inside the rectangular area of a control the LCL will send the > mouse event to this control. Without csOpaque it must change this check. > Same when clipping child controls. You need a new control TLayout derived from TGraphicControl but have new component state csSomthing to bypass mouse action at runtime and leave it other controls, but the real problem it must have child controls and that need hard coding make many new bugs. http://www.lazarus.freepascal.org/index.php/topic,4820.0.html

The stuff there is somewhat outdated.
TWincontrols and TControls are not separated anymore. You can write your own layout manager, but at the moment it is somewhat awkward. When the new auto size stuff is finished writing layout managers will be easier. Maybe we can even put the default layout code to another unit, saving 1-2% of exe size.

Mattias

Reply by email

Duncan Parsons
to Graeme Geldenhuys: To be fair, I did try and find help on csOpaque, but there was none. I then searched the…

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.

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).

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.

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.

HTH
DSP

Earlier message 45 lines
-----Original Message----- From: Graeme Geldenhuys [mailto:] Sent: 22 December 2009 14:32 To: Lazarus mailing list Subject: Re: [Lazarus] csOpaque seems to be broken in 0.9.29 Paul Ishenin wrote: >> > csOpaque is a hint which component gives to lcl whether it fully draws > itself or not. It does not mean that component should be drawn > transparently. To be fair, I did try and find help on csOpaque, but there was none. I then searched the LCL and found the following code with comment. I assumed from that, that csOpaque means the component will be transparent. ---------------------------------- constructor TCustomPanel.Create(TheOwner : TComponent); begin inherited Create (TheOwner); FCompStyle:= csPanel; ControlStyle := ControlStyle + [csAcceptsControls, csCaptureMouse, csClickEvents, csSetCaption, csDoubleClicks, csReplicatable, csNoFocus] - [csOpaque]; // we need the default background ... ---------------------------------- > Moreover it can't work for TWinControl which has a window > - HWND or GdkWindow since that windows are not transparent. So how else would you create a transparent container component in LCL? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ --

Reply by email

Mattias Gärtner
to Duncan Parsons

Zitat von Duncan Parsons :

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.

Show quoted text 5 lines
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

Reply by email

JoshyFun
to Zaher Dirkey: 2009/12/22 Mattias G?rtner : You need a new control TLayout derived from TGraphicControl…

Hello Lazarus-List,

Tuesday, December 22, 2009, 5:50:44 PM, you wrote:

ZD> You need a new control TLayout derived from TGraphicControl but have ZD> new component state csSomthing to bypass mouse action at runtime and ZD> leave it other controls, but the real problem it must have child ZD> controls and that need hard coding make many new bugs.

When I talk about transparent control I was talking in the sense of visually transparent, not in the sense of bypassing mouse clicks. Only a component that do not handle, in the windows world, the WM_ERASEBACKGROUND message. Also something like a non visual component that can have components inside could do the trick.

Best regards, JoshyFun

Reply by email

Graeme Geldenhuys
to Mattias Gärtner: Zitat von Graeme Geldenhuys : I will try again with other words: Let's assume you create…
Mattias G?rtner wrote
I will try again with other words:

Thanks, that explains it better. :-)

> csOpaque is then probably not the best chosen name for what LCL uses it for. AFAIK it is delphi compatible.

Ah, didn't know Delphi has such options.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Hans-Peter Diettrich
to Graeme Geldenhuys: To be fair, I did try and find help on csOpaque, but there was none. I then searched the…
> Moreover it can't work for TWinControl which has a window > - HWND or GdkWindow since that windows are not transparent. So how else would you create a transparent container component in LCL?

Some time ago I already suggested to introduce a new container or layout layer, between TControl and TWinControl. This TLayoutControl class could implement all kind of layout managers, e.g. anchor and tree docking (layout wise); the drag-dock support still could be reserved for windowed controls, depending on the widgetset constraints.

DoDi

Reply by email

Hans-Peter Diettrich
to JoshyFun: ZD> You need a new control TLayout derived from TGraphicControl but have ZD> new…
Show quoted text 7 lines
ZD> You need a new control TLayout derived from TGraphicControl but have ZD> new component state csSomthing to bypass mouse action at runtime and ZD> leave it other controls, but the real problem it must have child ZD> controls and that need hard coding make many new bugs. When I talk about transparent control I was talking in the sense of visually transparent, not in the sense of bypassing mouse clicks.

IMO transparent controls should be treated as having a glass surface - you can see buttons through the glass, but you cannot touch them. The glass only covers the intended client area of the control, everything outside its (possibly non-rectangular) border works as before.

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich
Show quoted text 14 lines
JoshyFun schrieb: > ZD> You need a new control TLayout derived from TGraphicControl but have > ZD> new component state csSomthing to bypass mouse action at runtime and > ZD> leave it other controls, but the real problem it must have child > ZD> controls and that need hard coding make many new bugs. > > When I talk about transparent control I was talking in the sense of > visually transparent, not in the sense of bypassing mouse clicks. IMO transparent controls should be treated as having a glass surface - you can see buttons through the glass, but you cannot touch them. The glass only covers the intended client area of the control, everything outside its (possibly non-rectangular) border works as before.

Transparent has many meanings. This is one of them. Another is non rectangular controls.

IMO: if something works like glass it should look like glass, which is not: 100% transparency.

Mattias

Reply by email

Graeme Geldenhuys
to Mattias Gaertner
Mattias Gaertner wrote
> IMO transparent controls should be treated as having a glass surface -

This is how I think of transparent too...

IMO: if something works like glass it should look like glass, which is not: 100% transparency.

OK, I'll work on a TGlassPanel component over my holidays. ;-)

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner: On Wed, 23 Dec 2009 08:20:09 +0100 Transparent has many meanings. This is one of them.…
Show quoted text 7 lines
> IMO transparent controls should be treated as having a glass surface - > you can see buttons through the glass, but you cannot touch them. The > glass only covers the intended client area of the control, everything > outside its (possibly non-rectangular) border works as before. Transparent has many meanings. This is one of them. Another is non rectangular controls.

See last sentence above ;-)

In the most general case the mouse-sensitive area can be a discontiguous region, leaving a "hole" inside a frame. But I found no real use for such a construct.

IMO: if something works like glass it should look like glass, which is not: 100% transparency.

Glass can have a color and a transparency from 0 to 100%, i.e. everything the widgetset(s) allows for.

DoDi

Reply by email

Funky Beast
to Hans-Peter Diettrich: See last sentence above ;-) In the most general case the mouse-sensitive area can be a…
Hans-Peter Diettrich wrote
In the most general case the mouse-sensitive area can be a discontiguous region, leaving a "hole" inside a frame. But I found no real use for such a construct.

Such a construct is common in designer (CAD) or custom built applications for mechanical/electrical/electronics/buildings engineering, where the "hole" inside that frame could contain other objects for dragging. Graphical modeling applications too.

Funky Beast.

Reply by email

Hans-Peter Diettrich
to Funky Beast
Show quoted text 8 lines
> In the most general case the mouse-sensitive area can be a discontiguous > region, leaving a "hole" inside a frame. But I found no real use for > such a construct. Such a construct is common in designer (CAD) or custom built applications for mechanical/electrical/electronics/buildings engineering, where the "hole" inside that frame could contain other objects for dragging. Graphical modeling applications too.

I thought about such applications, but just for dragging and other operations the controls inside the frame should *not* react individually, instead the frame should offer means (click, drag, context menu...) to deal with the group of *covered* components.

E.g. when some components shall become a composite object (macro cell...), or shall be otherwise handled as a group (property editor, copy/cut/move...), a temporary floating frame can be drawn around them, and then clicking on the frame starts the desired action on the covered components. When everything is done, the frame is removed again.

DoDi

Reply by email

Felipe Monteiro de Carvalho
to Hans-Peter Diettrich

Looks like this problem with transparent containers is inherited from Delphi:

http://docwiki.embarcadero.com/VCL/en/Controls.TControl.ControlStyle

Here csOpaque is defined as: The control completely fills its client rectangle.

And here describes and not very intuitive way to make a TPanel transparent:

http://groups.google.com/group/borland.public.delphi.vcl.components.writing/browse_thread/thread/90f253093d15820e/9385f971b8bf50a4?lnk=st&q=delphi+tpanel+transparent&rnum=2&pli=1

On the other hand I wonder if simply writing an empty routine to catch LM_ERASEBKGND and a Paint handler which doesn't paint wouldn't solve this issue and make a TWinControl transparent.

Felipe Monteiro de Carvalho

Reply by email

Zaher Dirkey
to Hans-Peter Diettrich: Then these controls are *on* (above) the glass, not under it. DoDi
Hans-Peter Diettrich wrote 9 lines
Zaher Dirkey schrieb: >> leaving a "hole" inside a frame. But I found no real use for such a >> construct. > > I useful to put controls on it with Align and Anchors. Then these controls are *on* (above) the glass, not under it.

The controls must over the layout (not the glass) the layout not just transparent also it bypass the mouse actions, so i can put many TLayout in my form to control the Size or Positions of my Controls. TLayout be more easy if inherited from TGrapghicControl so it not need to have any wedgets or depend on the OS.

TGlassControl is another kind of control depend on OS control, it is like TPanel but have 0..100 transparent, it is need more hard coding.

Zaher Dirkey

Reply by email

Graeme Geldenhuys
to Hans-Peter Diettrich: Some time ago I already suggested to introduce a new container or layout layer, between…

2009/12/23 Hans-Peter Diettrich :

Some time ago I already suggested to introduce a new container or layout layer, between TControl and TWinControl.

A few months ago I started a port of the Java MiG layout manager. Unfortunately work kept me very busy so I haven't had time to continue my efforts. Anyway, MiG layout can replace *all* layout managers, you only require one per form and is very feature rich. As far as I could see from the original Java source code, it should be easy to make the Object Pascal MiG layout a non-gui component that simply manages components on a form - if not, that is how I plan to implement it.

Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

Hans-Peter Diettrich
to Graeme Geldenhuys
Show quoted text 7 lines
> Some time ago I already suggested to introduce a new container or layout > layer, between TControl and TWinControl. A few months ago I started a port of the Java MiG layout manager. Unfortunately work kept me very busy so I haven't had time to continue my efforts. Anyway, MiG layout can replace *all* layout managers, you only require one per form and is very feature rich.

An installable LayoutManager would be very fine, just as the installable DockManager. Such a feature would simplify the implementation and debugging of layout managers in general - Mattias seems to be working on the current (hardwired) one?

DoDi

Reply by email