I totally agree. I'm not proud of this code.
The nicest solution would be a transparent layer on top of a form, together with paint messages, clipping and invalidates. But I guess, it will take some years, before we get this for normal window managers.

I suggest making the grabbers windows, derivative of a TCustomForm or so. I suggest using a window, derivative of TCustomForm, for drawing invisible components on.

I'm not sure, what you mean. Can you give more details?

Then it'll all be easier and cleaner. What do you think?

I like everything, that is more easier and cleaner and as fast as the current solution.

Mattias

+ -----Original Message-----
+ From: Mattias Gaertner
+ Sent: vrijdag 31 oktober 2003 14:43
+ To:
+ Subject: Re: [lazarus] GTK team: please specify! +
+
+ On Fri, 31 Oct 2003 12:51:10 +0100
+ Micha Nelissen wrote:
+
+ > >>> About TControlSelection.DrawGrabbers:
+ > >>> FGrabbers[g].Left/Top are holding the position of a
+ > >>> grabber relative to the client origin of the form.
+ > >>> The line
+ > >>> Diff:=DC.FormOrigin;
+ > >>> gets the DC origin also relative to the form origin.
+ > >>> Therefore the grabber is painted at FGrabbers[g].Left-Diff.X.
+ >
+ > Indeed. I have fixed the code.
+
+ No.
+
+ You changed the Diff, which is absolutely correct. The bug lies
+ somewhere in the calculation of DC.FormOrigin.
+ Maybe my lines above were ambigious. An example:
+ A designer form is at 100,200, has a TGroupBox at 30,30, with a
+ border of 5,5.
+ And there is an non visual component icon at 50,50. These 50,50
+ is relative to the client origin of the form. This means the
+ icon should be drawn at 15,15 in the client area of the groupbox.

That depends. For a form the origin of a DC is the client origin. I checked it a win32, and there it seems that either the groupbox has no border (clientorigin is top left) or the DC origin is not at the client origin. I guess the first. (the visual border is drawn on its own client area)

So in the win32 case the icon is draw at 20, 20.

+ Paint messages:
+ Don't take this example too serious, it is the system that is important.
+ When the LCL gets a paint message for the groupbox, the
+ designer gets also the paint message. The paint message
+ DC origin (0,0) is the left,top of the client area of the groupbox.
+ So, relative to the client area of the form it is 35,35 = DC.FormOrigin.
+ So, the icon (at 50,50) is painted at 15,15.

[kept values unchanged]

+ The DC.FormOrigin is calculated in designerprocs.pp
+ function TDesignerDeviceContext.GetFormOrigin: TPoint;
+ This function is platform independent. It uses
+ FormClientOrig:=FormClientOrigin;
+ DCOrig:=DCOrigin;
+ So, maybe you should test, if these two functions return
+ correct values in win32. I guess it will be DCOrigin,
+ because it uses GetWindowOrgEx. Probably we have to replace
+ this call by another interface function, which does not
+ yet exists.

YM, we have to calculate the offset of a given DC relative to the form ?

Ehm... Fillrect draws on a DC. The rectangle given is relative to the origin of the DC.

So now the big question is, what is the origin of a DC.

That depends.
GetDC(handle) returns the DC for the windowclient, thus the coordinates are relative to the client area.

GetWindowDC(handle) returns the DC for the whole window (including header and border), here the coordinates are relative to the topleft of a window.

In most cases I think we are using the first kind of DC. (note that in X we probably should both return the same, since we have no control over border etc)

On a normal DC the origin is 0,0

However for easy translations and background fills, one can move the DC origin. I wonder how often this functon is used. I can't remember I did ever.

None.

The only one I can think of is when you are working with the desktop DC :-)

Marc

No.

You changed the Diff, which is absolutely correct. The bug lies somewhere in the calculation of DC.FormOrigin.
Maybe my lines above were ambigious. An example:
A designer form is at 100,200, has a TGroupBox at 30,30, with a border of 5,5. And there is an non visual component icon at 50,50. These 50,50 is relative to the client origin of the form. This means the icon should be drawn at 15,15 in the client area of the groupbox.

Paint messages:
Don't take this example too serious, it is the system that is important. When the LCL gets a paint message for the groupbox, the designer gets also the paint message. The paint message DC origin (0,0) is the left,top of the client area of the groupbox. So, relative to the client area of the form it is 35,35 = DC.FormOrigin.
So, the icon (at 50,50) is painted at 15,15.

The DC.FormOrigin is calculated in designerprocs.pp function TDesignerDeviceContext.GetFormOrigin: TPoint; This function is platform independent. It uses

    FormClientOrig:=FormClientOrigin;
    DCOrig:=DCOrigin;

So, maybe you should test, if these two functions return correct values in win32. I guess it will be DCOrigin, because it uses GetWindowOrgEx. Probably we have to replace this call by another interface function, which does not yet exists.

Mattias

In win32 (and I guess in gtk also), windows have a certain z-ordering that can be influenced. (BringToFront, SendToBack and friends). Now if we make a special designer-type window, call it container, (which doesn't have to be in the LCL), in which we can draw what we want. So each of the grabberhandles is drawn in such a container. Each of the invisible components is drawn in such a container. The result is that we let the interface do the position and visibility calculations (that's what it's good at, after all) and we simply state their position relative to their parent which are simple calculations.

Is this clearer?

Micha.

FormOrigin calls TForm.GetClientOrigin which relative to the screen.

Relative to device context (= parent window in this case).

And more important: What function returns the DC origin relative to the screen?

In windows, device contexts have no size, and no position. So there is no function to get that directly.

You can, however, if the device context is one of a window, get the window using WindowFromDC, the get the origin of that window using ClientToScreen with (0,0) for example.

HTH,

Micha.

I think we're making this WAY too difficult and hackish with DC size/position calculations all over the place.

I suggest making the grabbers windows, derivative of a TCustomForm or so.

I suggest using a window, derivative of TCustomForm, for drawing invisible components on.

Then it'll all be easier and cleaner. What do you think?

Micha.

+ From: Mattias Gaertner
+ Sent: vrijdag 31 oktober 2003 16:22
+
+ On Fri, 31 Oct 2003 15:57:32 +0100
+ "Marc Weustink" wrote:
+
+ > From your example:
+ > Icon at 50,50.
+ > DC of groupbox at 30,30
+ >
+ > Suggestion:
+ >
+ > hwnd := GetWindowFromDC(GroupboxDC)
+ > P := Point(50, 50)
+ > MapWindowPoints(Form.Handle, hwnd, @P, 1)
+ >
+ > Now P should have the coords relative to the GroupBoxDC +
+ ok.
+ For optimization, I think, we should add a new interface
+ function, which use as default these 3 lines. For example function
+ MapWindowDCPositionToScreen(DC: HDC; const DCPosition: TPoint; var
+ ScreenPosition: TPoint): boolean;

Ehm... my lines calculate the position relative to the form, not the screen.
(or at leasdt that was what I had in mind).

+ The gtk will override it.

Why ?

GetWindowFromDC and MapWindowPoints are already widgetset dependant functions.

Marc

relative to clientorigin

2) (TGTKObject|TInterfaceBase).GetWindowOrgEx

screen

What is GetWindowOrgEx exactly supposed to return in the win32api?

Mattias

+ From: Micha Nelissen
+ Sent: donderdag 30 oktober 2003 9:00
+
+ Hi,
+
+ I need your help on these functions, are the coordinates specified in
+ clientrect coordinates or screen coordinates:
+
+ 1) (TGTKObject|TInterfaceBase).FillRect
+ 2) (TGTKObject|TInterfaceBase).GetWindowOrgEx

If they are win32 api functions (what they from name look like), the general rule is that they behave te same as their win32 counterparts

Marc

Indeed. I have fixed the code. I hope GTK still works...

Micha.

About TControlSelection.DrawGrabbers:

FGrabbers[g].Left/Top are holding the position of a grabber relative to the client origin of the form.
The line
Diff:=DC.FormOrigin;
gets the DC origin also relative to the form origin. Therefore the grabber is painted at FGrabbers[g].Left-Diff.X.

Is the 15,20 relative to the screen or the parent window? And more important: What function returns the DC origin relative to the screen?

Mattias

As said in reply to mattias, this should be the case, but it is not, as far as I can see, but I haven't found the precise cause yet.

Micha.

Right. The border depends on the interface. But this is nothing the designer need to worry about. It just asks the interface about the client origin. BTW: The 5,5 was just an example. I have never seen a groupbox with such borders.

Yes. For various reasons. For example:
- Non visual components coords are form relative
- While moving controls, the control coords can be out of sync between lcl and interface. The only fixed point is the form.
- On slow computers, the mouse event queue of the interface gets filled up. Therefore the designer uses absolute mouse coords, which can easily be translated to the form, but not to the controls.
- ...

ok.
For optimization, I think, we should add a new interface function, which use as default these 3 lines. For example function
MapWindowDCPositionToScreen(DC: HDC; const DCPosition: TPoint; var ScreenPosition: TPoint): boolean;
The gtk will override it.

Mattias

MapWindowPoints needs to calculate the screen coords of both handles to create the diff (at least O(n)). The designer needs this function on some forms several thousand times per draw. Therefore I implemented the TDesignerDeviceContext, which cashes the positions. This accelerates some forms by factor 2. So, the calculation of the diff should be doable by the designer.

Mattias

Indeed, but IN the groupbox ! If I now move the groupbox, windows remembers it's painted image and the invisible component moves with it. How is this handled?

Micha.

Doesn't seem to be so when testing controlselection.pp, DrawGrabbers... FillRect is passed the screen-relative points of the grabber handle instead of client-origin. But this may be a problem in DC.FormOrigin instead... I removed in my local copy the Diff subtraction from the grabbers.left,top and then it was drawn at the correct location on win32.

Returns the current drawing origin within the current device context. So drawing a pixel at 10,15 with origin of 15,20 will draw a pixel at 25,35.

Micha.

Hi,

I need your help on these functions, are the coordinates specified in clientrect coordinates or screen coordinates:

1) (TGTKObject|TInterfaceBase).FillRect
2) (TGTKObject|TInterfaceBase).GetWindowOrgEx

I cannot fix win32 without either:
1) breaking gtk drawing
2) knowing this info.

Breaking would consist of drawing the grabbing handles, non-windowed component in the wrong place because client-screen coordinates are confused. Currently this IS the case in win32 so we need a common specification to make it work properly.

Please help! :).

Thanks,

Micha.

Yep. I was talking about a paint message for the groupbox. You can't paint with a paint message for a form on every control of the form, because of the internal clipping of the interface. If the interface is capable of sending one paint message for the whole form, then the designer could use only this message. But as we didn't had such an interface, it is not yet supported.

If I now move the groupbox, windows remembers it's painted image and the invisible component moves with it. How is this handled?

Normally, moving a control, should invalidate it, which result in a paint message for the control, which will automatically repaint the control and the designer will repaint the icon (at the new position, so that it appears to be fixed).

Mattias

Because I didn't know the trick to get a device context for this, the gtk interface was young and unflexible and the message queue unordered. Now, I know the trick and the gtk interface has everything we need. Now I will do it.
Because this was always my goal, the designer needs only little changes for this.

Mattias

I have implemented GetDesignerDC for win32. Screen relative positions. Works reasonably well. I can see the grid alignment lines now :). But: things drawn onto controls are left behind. I assume nothing is drawn into controls DC's anymore, only to the designer DC?

Micha.

Just found out that clipping can be set by gdk though gdk_gc_set_subwindow. Options are:
GDK_CLIP_BY_CHILDREN only draw onto the window itself. GDK_INCLUDE_INFERIORS Draw onto the window and child windows.

[snip]

Where does that leave us? OTOH, it is possible to create transparent window in the win32 interface. Is it too in gtk?

GDK can it. gdk_window_shape_combine_mask and co

Marc

This is determined at control creation time, there isn't a seperate function for that. CreateWindow help:

----
WS_CLIPCHILDREN: Excludes the area occupied by child windows when drawing occurs within the parent window. This style is used when creating the parent window.
WS_CLIPSIBLINGS: Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated. If WS_CLIPSIBLINGS is not specified and child windows overlap, it is possible, when drawing within the client area of a child window, to draw within the client area of a neighboring child window.
----

Where does that leave us?

OTOH, it is possible to create transparent window in the win32 interface. Is it too in gtk?

Micha.

Mattias Gaertner wrote

Much more clearer :) I was a little bit confused by the term "derivative of TCustomForm".

Well, I meant descendant I think, ie. a windowed control.

Ok, grabbers and icons can be replaced by special non LCL widgets (in win32 slang: windows). What about the rubberband, the selection marks and the guide/snap lines?

Rubberband can be drawn on the screen itself. It's temporary, after all. Is this possible in gtk too?

Selection marks aren't the grabber handles?

Guide/snap lines are the grid, the dots? These are not inter-control, are they? Only things that require inter-control calculations should be redone. Or is this too simply thought?

We can try to implement things one by one, first the invisible components, then the grabber handles, etc...Then dependencies will show gradually. Or do you want a complete rewrite from scratch?

Micha.

The interface to gtk is implemented using the winapi, right? I just want to know whether the GetDesktopWindow call can be implemented.

Micha.

> > >Where does that leave us?

I have implemented the new interface function GetDesignerDC. The designer now uses this to draw the Grabbers, Guide Lines, Non Visual Component Icons and the Rubberband. This means the designer now paints these items only once and on top. It does not accelerate much, because the designer used clipping. But at least there is now no control left, that hides the icons. Now we have to implement the new coord function for the win32 and the gtk interface and then it should work under both. The function should return the origin of a DC relative to the screen or the form. At the moment under gtk this is GetWindowOrgEx. But as Micha pointed out, this is wrong and need to be fixed.

One definition for Transparent windows is that you can see through. For example, that you can see the window below or ("less" transparent) the desktop background. Others even want alpha. All three options need the help of the WM. AFAIK gtk1's transparency is quite limited. gtk2 supports much more. But afaik it still needs an advanced WM.

Mattias

So the places where a child window/widget is located are not drawn ? Strange behaviour. And not very efficient.

Michael.

Yes, that's what I found out on sunday. I already got a running version with this, but I need some time for clean up.

It depends how you define "Transparency".

Mattias

The WinAPI specifies that GetDC(GetDesktopWindow()) should return a device context of the screen. We can use this DC to draw on.

Hmm, no. These are drawn on the control, within control bounds. Black ones are partially on control, partially on parent, but these gray ones are completely on the control.

Indeed, I have never seen them. I guess we can leave these for later?

Delphi recommends descending from TCustomControl in this case. From help:

"TCustomControl is one of two base classes for controls that draw their own surfaces. Because TCustomControl is descended from from TWinControl, instances of its descendents can receive the focus and serve as containers."

HTH,

Micha.

Yes. But I'm not sure, how to combine this with the LCL/IDE.

Selection marks aren't the grabber handles?

No, I mean the multiselection marks (normally gray 4 rectangles at each corner of each component). When the user selects 10 components, should we then create 40 small widgets?

Guide/snap lines are the grid, the dots?

No, this is the grid. I mean the green and blue lines showing the alignment of the selection with other controls on the form. Maybe you never saw them, because Delphi does not have them and the designer does not yet work under win32.

No, every item (grabbers, marks, snap lines, grid, icons) is already splitted up. So, we can replace them one by one.
What we need are LCL widgets, that are not controls. Maybe we can call them TDesignerWidget. (Not TDesignerControl, because they have nothing to do with TControl, not even with TComponent). They should be as separate from the normal LCL routines as possible. For example: No messages.

Mattias

No. The form canvas uses a standard DC. And this DC provided by the gtk has clipped the child gdkwindows away.

Of course the designer uses a canvas to paint. It will simply work like this:

DesignerCanvas:=TCanvas.Create;
DesignerCanvas.Handle:=GetDesignerDC(Form.Handle);
.. paint ..

Mattias

Sorry, I don't quite get the answer: you will draw on the form canvas or not ?

And why do you need the DC ? You could just as well use the canvas methods ? I don't know about Lazarus, but Form.Canvas is an existing property in Delphi. It would make the code also 100% portable, without need for backend changes. After all, Canvas is just a Delphi wrapper around a DC, so why not use it ?

Michael.

Ok. Maybe I found the solution.
Now to the LCL.

GetDC will just return the "normal" device context for a window. Under gtk this is without the child windows (they are clipped away). The designer needs a DC with childs. Something like GetRawDC or GetWholeDC or GetDCForWholeWindow or GetDesignerDC or ... . I guess under win32api this is already the default, so you have little to do. If not, how does win32api calls it?

Mattias

Maybe a stupid suggestion, but why don't you draw all that on the form window/canvas ? All widgets/controls must always be somewhere on the form. Also, if you move widgets over parent boundaries (which can happen) the designer handles can still be drawn, since their coordinates are relative to the form window, not relative to the parent.

Michael.

Very funny. ;)
What has the winapi to do with the gtk?
We need the window DC without clipping and we need an event to know, when the gtk has finished painting everything. And during moving we have to paint as well.
When we got this, we can omit the paint on every message and we can omit the designer widgets, because the rest is already implemented. This solution would be very near to my initial wish in a former mail. I will do some experiments...

Then we still need the paint messages. Using widgets for the grabbers will only be a small optimization.

We can leave the implementation for later, but IMO we must find a solution for this. Otherwise we have to keep the DC hacks. And without making the rest more simple, it does not make sense to add special widgets .

If we use any TControls, then we have to add code to various places in the LCL to distinguish between "real" controls and "only designer" controls. IMO this will become a mess.
If we want to implement a more clean solution, then we should create separate widgets.

Mattias

Thats the same I was thinking of. That will be enough for us.

For example, that you can see the window below or ("less" transparent) the desktop background. Others even want alpha. All three options need the help of the WM. AFAIK gtk1's transparency is quite limited. gtk2 supports much more. But afaik it still needs an advanced WM.

I don't think only WM, but more X. From the doc's I understand that this transparent function is not supported on some older version of X.

Marc

Much more clearer :)
I was a little bit confused by the term "derivative of TCustomForm".

Ok, grabbers and icons can be replaced by special non LCL widgets (in win32 slang: windows).
What about the rubberband, the selection marks and the guide/snap lines?

Mattias

Mattias Gaertner wrote

On Mon, 03 Nov 2003 01:32:28 +0100 Marc Weustink wrote:

[snip]

Ah, I was looking for transparency in GDK2 and saw this function. And I also found out why we didnt use it before, it's so well documented in GDK1 ;)

Ehm, I didn't try it, but I assumed something like you define some areas of a window wich are visible and the other part you dont see. Something like Xeyes.
From your reply I guess we're talking about transparent black or something ?

Marc

My first reaction would be: It can't.

How strange this may sound, but gtk has no desktop. The windowmanager has (I guess). But since the window manager has access to the desktop, why cant we.

So to answer your question, it probably is possible, but don't expect it implemented soon.

Marc

Wow :-)

I didn't know that you could draw on top of other controls. I always thought that the controls whithin a window were painted after the form was painted.
Something learned today.

Only one small bug found when you move a component to the right (or bottom), off the form. The grabbers are pushed off while the icon stays at the border

Marc

I've been testing all controls and I see this behaviour in Linux/Gtk also on some controls. When moving a component (TTimer) over a control: TEdit, then bottom and right border keep trails of the grabbers TMemo, when moving over a TMemo, the topleft grabbers and border of the component are left behind.
TListBox, you can draw whith the component :-) The complete image of the component is left behind.

Another thing I noticed is that you cant place anything in front of a TCalendar, also no components

Marc

Ok, I have implemented an InvalidateRect-invalidates-children-too type of InvalidateRect. I believe it's now compatible to the gtk bugs :), e.g. the small lines left behind.

I'm not sure, if the boundings are always correct. This is a non deterministic process. I have to debug this someday.

Good luck! ;). I will also see if I can find something, but don't count too much on it :).

Micha.

No. The following is used:

     InvalidateRect(FForm.Handle,@OldRect,false);

I'm not sure, if the boundings are always correct. This is a non deterministic process. I have to debug this someday.

Mattias

Correct. (hehe. Now you are confused, right? )

See my other mail. I'm not yet sure, if it is a bug of the paint or the invalidate part of the designer.

Mattias

Do you call InvalidateRect too on the control on which is painted? The grabbers, for example, are partly on form, partly on control. InvalidateRect is being called for the form, but is it called for the control too?

Micha.

Yes, those :).

A lot more :). For example: placing a TGroupBox into the form and then placing a button in that groupbox, selecting it. Then move the button: a trail of complete square boxes of markers is left behind. Not a 1-pixel line, but the full 10 by 10 pixel box or so. All blue and green lines are left behind on controls, so moving them around a little bit and they all have blue and green borders :). Do you know the cause, solution?

Micha.

Grid alignment lines? :)
I guess, you mean the blue and green guide lines.

But: things drawn onto controls are left behind. I assume nothing is drawn into controls DC's anymore, only to the designer DC?

Markers and grids are painted per control paint messages. The invalidate rectangles are not big enough. Not a big thing. This is a known issue. Although with the new technique it appears more often.

Mattias

Sounds as if the InvalidateRect does not work properly under win32. Or too good.

Mattias

Bad luck for you. ;)
The designer works nice. It simply invalidates everything, where it has painted. All the bugs for the gtk intf are in the gtk itself. So, I guess, there are some bugs left in the win32 intf.

Mattias

This is a gtk bug. InvalidateRect uses gtk_widget_queue_draw_area. The gtk does not adjust the rectangle for the child gdkwindows. Many child windows have a small offset. I have added 3 Pixel extra invalidate for the design items, so that they now seem to work.

It seems these two widgets use some tricks.

Mattias