This CONTROL.LEFT error has existed for quite some time. I had mentioned it quite some time ago but haven't been able to look at it to determine where it gets messed up.

This causes quite a few problems. One of them is the problem when grabbing and moving controls. This needs to be looked into and I would love it if someone would volunteer to get to the bottom of this error...

Shane

>> 10/09/00 05:52PM >>>

Hi, after all I found some time to grab my keyboard and add some changes:

* fixed some selection code
Original code worked in delphi but didn't with FPC. It seems that private member vars are public in descenant objects.

    IE: with MyObjectDerivedFromTControl do Left := FLeft
    doesnt do anything since TControl has a private FLeft so this
    example is referring to TControl.FLeft and not your FLeft
  + Added selection sample
     To show whats going on. I really don't get it. Somehow
     out TControl.Left property gets messed up. (look at the debug
     output)
    BTW, don't play to long with this sample, It triggers an
    resource bug consuming loads of resources and memory. A
    few minutes of clicking and dragging result in a swapping
    machine, where with luck you have an open console and manage
    to enter killall selection :(

Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

+ From: Shane Miller
+
+ This CONTROL.LEFT error has existed for quite some time. I
+ had mentioned it quite some time ago but haven't been able to
+ look at it to determine where it gets messed up. +
+ This causes quite a few problems. One of them is the problem
+ when grabbing and moving controls. This needs to be looked
+ into and I would love it if someone would volunteer to get to
+ the bottom of this error...

You can see this behaviour in the Selection example I submitted. In that example there is also a button for drag testing.

It is BTW not only the CONTROL.LEFT property CONTROL.TOP has it as well (a bit less but it has it)

As far as I can see, this problem is only visible during dragging. I think that is has something to do with moving a control whith the mouse over it. In this case it is probably not defind which event ocours first, the control moved event or the mouse moved event (if you move a control while the mouse is at the same screen location, it is in fact a mouse move for the control)

Dragging the selection shows some funny results. The grabbers are moved with the same delta as the button, but on screen this doesn't look so (sometimes)

A solution might be to forget the mouse pos you get from a GTK event (it is relative to a control) but calculate it ourselfes from the screen position (this wayt we also solved drag mouse movement outside out control)

Marc

Hi, after all I found some time to grab my keyboard and add some changes:

* fixed some selection code
Original code worked in delphi but didn't with FPC. It seems that private member vars are public in descenant objects.

    IE: with MyObjectDerivedFromTControl do Left := FLeft
    doesnt do anything since TControl has a private FLeft so this
    example is referring to TControl.FLeft and not your FLeft
  + Added selection sample
     To show whats going on. I really don't get it. Somehow
     out TControl.Left property gets messed up. (look at the debug
     output)
    BTW, don't play to long with this sample, It triggers an
    resource bug consuming loads of resources and memory. A
    few minutes of clicking and dragging result in a swapping
    machine, where with luck you have an open console and manage
    to enter killall selection :(

Marc