Login ProductsSalesSupportDownloadsAbout |
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 |
Rick | 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 |
Thu, Jul 10 2014 3:57 AM | Permanent Link |
Matthew Jones | 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 |
Thu, Jul 10 2014 10:22 AM | Permanent Link |
Rick | 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 |
Thu, Jul 10 2014 11:51 AM | Permanent Link |
Matthew Jones | 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 |
Thu, Jul 10 2014 9:02 PM | Permanent Link |
Rick | 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 |
This web page was last updated on Friday, November 1, 2024 at 07:01 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |