Hi.

It seems that the X and Y values provided by the OnMouseDown event are
relative to the pointer's position on the desktop rather than the
component that the event is defined to.

For example, define a large desktop height and width, place a label in
the bottom, right-hand corner of the form and add an OnMouseDown event
handler for the form. In the event code display the X and Y values in
the label.

Run the application and make sure that the desktop is scrolled all the
way to the top. Click the form somewhere near the label and note the
values displayed in the label.

Now, scroll the desktop down so that the label is near the top of the
desktop but still visible. Click the form in the same place as before
and note that the Y value is much smaller than before. In fact it seems
to be relative to the top of the visible part of the desktop.

Should the X and Y values be relative to the top of the form regardless
of desktop scroll or form positioning?

Probably won't get a response from Tim but I'm just wondering if the
OnMouseDown X and Y values are being calculated correctly? I suspect
that they should be relative to the form's client area. If others agree
then I will raise a problem record.

--
Rick

Rick wrote:

> Hi.
>
> It seems that the X and Y values provided by the OnMouseDown event
> are relative to the pointer's position on the desktop rather than the
> component that the event is defined to.


I think it is "screen coordinates" in Delphi terms, so sort of the
desktop. I have the following code in my routines to work out where on
the particular component it actually is.

procedure TfrmVote.imgThingMouseMove(Sender: TObject; ShiftKey,
CtrlKey, AltKey: Boolean; X,Y: Integer);
var
   xObject : TControl;
   xParent : TControl;
begin
   if m_bDragging then
   begin          
       if Sender is TControl then
       begin
           xObject := TControl(Sender);
           while xObject <> self do
           begin
               xParent := xObject.Parent;
               X := X + xObject.Left;
               Y := Y + xObject.Top;     
                      
//                SelectPanel(xObject);
               xObject := xParent;
           end;
       end;

--

Matthew Jones

On 10/07/14 17:57, Matthew Jones wrote:
> I think it is "screen coordinates" in Delphi terms, so sort of the
> desktop.
>
Yes, it does appear as though EWB is using the screen coordinates
approach which in this case seems to be the browser window itself. This
makes for moderately complex code when trying to determine the position
within the control and could result in performance degradation which is
never good in javascript.

The EWB help doesn't say anything about the X and Y values in the
TMouseDownEvent type however it does say the following in the
TMouseMoveEvent type:

"... and the X and Y parameters indicate the coordinates of the mouse
pointer relative to the control."

This seems to imply that X and Y should be offset relative to the
associated control which means the values should not change even when
the desktop is large and browser scrolling is enabled.

Do you understand the help this way Matthew or am I misunderstanding the
intent?

I tried the OnMouseMove event for the form and noticed the same
situation as with OnMouseDown. The X and Y values differed depending on
how the browser was scrolled even though the pointer was moved over the
same part of the form.


--
Rick

Rick wrote:

>  The X and Y values differed depending on how the browser was
> scrolled even though the pointer was moved over the same part of the
> form.

Ah, I missed that. You have to take into account the ScrollTop part of
the component's properties if scrolling within it is possible.

Fundamentally it is all logical - a little experimentation as you are
doing answered all my questions on it, and I was able to work out what
I was over etc and take appropriate actions.

--

Matthew Jones

On 11/07/14 01:51, Matthew Jones wrote:
> Rick wrote:
>
>>   The X and Y values differed depending on how the browser was
>> scrolled even though the pointer was moved over the same part of the
>> form.
>
> Ah, I missed that. You have to take into account the ScrollTop part of
> the component's properties if scrolling within it is possible.
>
> Fundamentally it is all logical - a little experimentation as you are
> doing answered all my questions on it, and I was able to work out what
> I was over etc and take appropriate actions.
>
The form itself is not scrollable, only the large desktop on which the
form resides. The form is non-scrollable and a static size.

I would have thought that the pointer coordinates within the client area
of the form would be the same regardless of how the desktop has been
scrolled.


--
Rick