Sign in Join

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

Mailing lists / lazarus / 2003-07

Patch for win32 : GetRelativePosition

8 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

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

Karl Brandt

I'm sending a patch with a implementation for win32 interface of the cited procedure. This time, i think it's a correct one.

It also refine WM_MOVE : now, not Forms controls send the correct position
There's two way of testing if is Form/Not child in the patch. I'll let to Mattias to decide wich one to pick. I think the result is the same.

BTW: How time/resource consuming are Is and As operators?. I'm afraid that using these in interfaces can degradate the performance

there's two problems in the generic (interfacebase) version of this procedure:
First, the ParentLeftTop var is not initialized, returning random values. Second, the ClientToScreen procedure returns the screen position of a coordinate relative to the client area of the supplied window, which is not useful in this case.
These was causing the child controls to not display, and making the ide/big applications to consume the memory in minutes (why??)

It can be implemented in a similar way i did.

karl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00013.zip
Type: application/octet-stream
Size: 918 bytes
Desc: "GetRelative2.zip"
Url : http://localhost/pipermail/lazarus/attachments/20030720/048f32ab/zip00013.obj

Reply by email

Marco van de Voort
to Karl Brandt: Thanks Thanks What do you think about using Is and As? Sorry. I was thinking that you…
and the memory usage grows quickly. Do you know where i can find teorical documents about memory issues (leaks) and pascal?

No, but compiling OPT="-ghl" will print them with unit name and line number if you are lucky, and can leave the application gracefully.

(if you are not, something in the rtl/fcl allocates them, and you would need to recompile those too)

Reply by email

Marco van de Voort
to Karl Brandt: Thank you very much karl
Show quoted text 15 lines
Marco van de Voort wrote: >>and the memory usage grows quickly. >> >>Do you know where i can find teorical documents about memory issues >>(leaks) and pascal? > > > No, but compiling OPT="-ghl" will print them with unit name and line number > if you are lucky, and can leave the application gracefully. > > (if you are not, something in the rtl/fcl allocates them, and you would need > to recompile those too) Thank you very much

(also check the buildfaq I mentioned earlier, it describes recompiling a FPC snapshot with "special" parameters)

Please report back your experiences in general with -gh(l) I need feedback for that buildfaq :-)

Reply by email

Karl Brandt
to Marco van de Voort: No, but compiling OPT="-ghl" will print them with unit name and line number if you are…
Marco van de Voort wrote 11 lines
>and the memory usage grows quickly. > >Do you know where i can find teorical documents about memory issues >(leaks) and pascal? No, but compiling OPT="-ghl" will print them with unit name and line number if you are lucky, and can leave the application gracefully. (if you are not, something in the rtl/fcl allocates them, and you would need to recompile those too)

Thank you very much

karl

Reply by email

Karl Brandt
to Karl Brandt: I'm sending a patch with a implementation for win32 interface of the cited procedure.…
Mattias Gaertner wrote 11 lines
On Sun, 20 Jul 2003 01:53:37 -0300 Karl Brandt wrote: >I'm sending a patch with a implementation for win32 interface of the >cited procedure. This time, i think it's a correct one. Applied.

Thanks

Show quoted text 15 lines
>It also refine WM_MOVE : now, not Forms controls send the correct >position >There's two way of testing if is Form/Not child in the patch. I'll let >to Mattias to decide wich one to pick. I think the result is the same. > >BTW: How time/resource consuming are Is and As operators?. I'm afraid >that using these in interfaces can degradate the performance > >there's two problems in the generic (interfacebase) version of this >procedure: >First, the ParentLeftTop var is not initialized, returning random values. Fixed

Thanks
What do you think about using Is and As?

Show quoted text 17 lines
>Second, the ClientToScreen procedure returns the screen position of a >coordinate relative to the client area of the supplied window, Hmm. Sounds exactly like what we need. My idea was the following: "GetWindowRelativePosition" should return the same as the "Left", "Top" properties of a TWinControl. The Left, Top are defined as relative to the client origin of its parent. For example: A wincontrol at screen coordinates 200,100 with a 10 pixel broad frame, has a client origin in screen coordinates at 210,110. A child wincontrol with Left=30, Top=20 will be at the screen coordinates 240,130. GetWindowRect for the ChildHandle will return 240,130. ClientToScreen(0,0) for the ParentHandle will return 210,110. The difference is the Left, Top: 30,20.

Sorry.
I was thinking that you wanted to pass (Parent.Left,Parent.Top) ;-)

Show quoted text 8 lines
>which is not useful in this case. >These was causing the child controls to not display, and making the >ide/big applications to consume the memory in minutes (why??) Maybe it was due to uninitialized ParentLeftTop?

I will take a look.
Fixing only the interface proc the main ide runs without (many) problems, but opening the Envir Options forms, the form is not painted and the memory usage grows quickly.

Do you know where i can find teorical documents about memory issues (leaks) and pascal?

>It can be implemented in a similar way i did.

karl

Reply by email

Karl Brandt
to Karl Brandt: I'm sending a patch with a implementation for win32 interface of the cited procedure.…
Mattias Gaertner wrote 7 lines
>What do you think about using Is and As? They are fast enough for messages. There should be only a few thousand messages per second. If there are more, then the application is not very optimized and the IS and AS are secondary. Of course you should not use IS and especially not AS ten times in a common message.

Thanks

Karl

Reply by email

Mattias Gaertner
to Karl Brandt: I'm sending a patch with a implementation for win32 interface of the cited procedure.…
I'm sending a patch with a implementation for win32 interface of the cited procedure. This time, i think it's a correct one.

Applied.

Show quoted text 11 lines
It also refine WM_MOVE : now, not Forms controls send the correct position There's two way of testing if is Form/Not child in the patch. I'll let to Mattias to decide wich one to pick. I think the result is the same. BTW: How time/resource consuming are Is and As operators?. I'm afraid that using these in interfaces can degradate the performance there's two problems in the generic (interfacebase) version of this procedure: First, the ParentLeftTop var is not initialized, returning random values.

Fixed

Second, the ClientToScreen procedure returns the screen position of a coordinate relative to the client area of the supplied window,

Hmm. Sounds exactly like what we need.
My idea was the following:
"GetWindowRelativePosition" should return the same as the "Left", "Top" properties of a TWinControl. The Left, Top are defined as relative to the client origin of its parent. For example: A wincontrol at screen coordinates 200,100 with a 10 pixel broad frame, has a client origin in screen coordinates at 210,110. A child wincontrol with Left=30, Top=20 will be at the screen coordinates 240,130.
GetWindowRect for the ChildHandle will return 240,130. ClientToScreen(0,0) for the ParentHandle will return 210,110. The difference is the Left, Top: 30,20.

which is not useful in this case. These was causing the child controls to not display, and making the ide/big applications to consume the memory in minutes (why??)

Maybe it was due to uninitialized ParentLeftTop?

It can be implemented in a similar way i did.

Mattias

Reply by email