[lazarus] GTK team: please specify!

Mattias Gaertner nc-gaertnma at netcologne.de
Fri Oct 31 10:11:23 EST 2003


On Fri, 31 Oct 2003 15:57:32 +0100
"Marc Weustink" <marc.weustink at cuperus.nl> wrote:

> 
> 
> + -----Original Message-----
> + From: Mattias Gaertner [mailto:nc-gaertnma at netcologne.de]
> + Sent: vrijdag 31 oktober 2003 14:43
> + To: lazarus at miraclec.com
> + Subject: Re: [lazarus] GTK team: please specify!
> +
> +
> + On Fri, 31 Oct 2003 12:51:10 +0100
> + Micha Nelissen <M.Nelissen at student.tue.nl> 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.

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.


> + 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 ?

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

> 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;
The gtk will override it.


Mattias






More information about the Lazarus mailing list