|Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread|
|Messages 1 to 5 of 5 total|
|OnMouseDown X,Y relative to what?|
|Wed, Jul 9 2014 11:15 PM||Permanent Link|
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
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.
|Thu, Jul 10 2014 3:57 AM||Permanent Link|
> 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);
xObject : TControl;
xParent : TControl;
if m_bDragging then
if Sender is TControl then
xObject := TControl(Sender);
while xObject <> self do
xParent := xObject.Parent;
X := X + xObject.Left;
Y := Y + xObject.Top;
xObject := xParent;
|Thu, Jul 10 2014 10:22 AM||Permanent Link|
On 10/07/14 17:57, Matthew Jones wrote:
> I think it is "screen coordinates" in Delphi terms, so sort of the
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
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
"... 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
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.
|Thu, Jul 10 2014 11:51 AM||Permanent Link|
> 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
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.
|Thu, Jul 10 2014 9:02 PM||Permanent Link|
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
> 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
This web page was last updated on
Thursday, March 30, 2023 at 10:19 AM
© 2023 Elevate Software, Inc. All Rights Reserved
Questions or comments ? E-mail us at firstname.lastname@example.org