MouseX and MouseY in 2021r3

Having slept on my response from 5 days ago and having thought about this some more in light of its reoccurrence;

Using 2021r2.1 or older can anyone here produce a demo that shows a difference between me.mousex (the control’s mousex position) and self.mousex (the window’s mousex position) when inside a canvas (for example) either on a windows or in a container control?

Either I’m having a senior moment, my version of xojo is broken or they are both reporting the same value which would indeed make its removal understandable as the same value can be obtained already. From my limited test it would seem that Control.MouseX/Y has not been reporting a measurement from the top-left corner of the control for a long time (see <https://xojo.com/issue/29359> and <https://xojo.com/issue/29372>) so I’m not really sure what the alarm is in its removal as the same value can be obtained with Self.MouseX/Y?

That being said, I’m not really sure this wasn’t mentioned in the ticket or why @Paul_Lefebvre changed the docs on the 15th of November to say its measured from the top left corner of the control which would actually have been a useful feature if it were the case.

Yeah, well that’s the point. Why would they remove an innocuous read-only function just because it can be gotten another way? That’s like saying they should remove the highway system because there are other routes to wherever you are going. By removing MouseX and MouseY it forces anyone who used them to either stay with API1 controls or go “fix” code that otherwise would, and used to, work.

2 Likes

Because they are tidying up their language, making it more succinct with less avenues for issues to creep in and less confusion, like why does the MouseX position on a control actually return the MouseX position on the window?

4 Likes

Yeah, it should have, I agree. Which brings up the question, is there a way to get the mouse position in a control when the event isn’t one that returns X and Y? For example, how can you locate the mouse position on a keypress? Is the only way to calculate it using the control’s Top and Left values and the Self.MouseX and Self.MouseY (which are relative to the Window) or the System.MouseX, .MouseY (which are relative to the screen)?

If you want other behaviour it’s pretty easy to subclass. Having properties and methods that are (99% of the times) unused seems a waste and makes the docs confusing. Getting the location of mouse on a control (coords) means you can return them from your own property or method. That won’t be too hard. I don’t see a need for where you want the coords on a button while they are actually outside of the button for exampe, so the events are good enough or am i missing something here?

Using the code Anthony kindly provided here with a few tweaks:

Public Function MouseX(extends r as DesktopUIControl) As Integer
  // For the control referenced, figure out the local MouseX position by walking up the containment hierarchy.
  Dim retValue As Integer = r.Window.MouseX - r.Left
  
  Dim p As Object = r.Parent
  
  Dim container As DesktopContainer
  
  While p <> r.Window
    if p isa DesktopUIControl then
      p = DesktopUIControl( p ).Parent
    ElseIf p IsA DesktopContainer Then
      container = DesktopContainer( p )
      retValue = retValue - container.Left
      p = container.Parent
    end if
  Wend
  
  Return retValue
End Function
4 Likes