MouseX and MouseY in 2021r3

Could someone please explain to me the logic(?) behind removing MouseX and MouseY from the various DesktopUIControls? How are we to track the movement of the mouse in a control?

I often use the X and Y location of the mouse in a control to position a popup window or canvas and would hate to have to calculate it from the System.MouseX (and Y) every time the mouse moves.

I can’t explain the logic, even though it’s been explained to me.

The workaround is to cache it in the mouse events on a subclass of a canvas, window, whatever you need, to MouseX and MouseY properties.

This is what Paul said:

So, now you only need to create a subclass, add a variable for X, one for Y, use the super MouseMove event to update the values, declare another MouseMove event for the sublcass and Raize it… :neutral_face:

Awesome! really helpull new feature :roll_eyes:

Don’t forget to set X and Y to -1 in the MouseExit event.

1 Like

I’m not a big fan of removing stuff, but can you think of a case when you ever need MouseX and Y for a control when its MouseMove event has not fired?

1 Like

In a timed drawing based on mouse position. This can provide smooth mouse-based drawings at reduced CPU usage compared to the drag event.

1 Like

In that case, those properties should be put back into the framework.


Take a look at the CellBorder thread…

My personal opinion is that it is part of a new ongoing effort at Xojo Inc trying to remove features they think are superfluous mainly to make maintaining the Framework easier for them despite the inconvenience to users…

It looks like they want to see how many holler about the missing conveniences to see if they can get away with keeping them out… But they have made so many changes so many have disagreed with, that people start feeling there is no point in complaining about such things.

IMO it is a whole bunch of such little “superfluous” things that makes the product more productive and more RADish for us, and easier for newbies to get started with doing things a bit beyond the bare basics…


1 Like

Odd, the docs were changed recently, Control.MouseX now says its from the top-left corner of the control, which it never was as I can see in the in built LR from previous versions where it clearly says its from the top-left of the window. I hope this wasn’t changed to make its removal seem less impactful, but I can’t really see why they would change it to be what is essentially incorrect now.

This means you now have to traverse the controls parents to work out where the control actually is on the window before you can apply the offset of Window.MouseX and it’s now no longer as trivial to work out if the mouse is to the left of the control, something that is useful for snaplines/guidelines that follow the cursor when you are outside the control or even a custom cursor that follows the cursor around the edge of the control when the mouse isn’t insode.

Seems like another “we don’t use it so you don’t need it”.


I’m pretty sure Control.MouseX / MouseY has always been relative to the control.

Nope, I checked before I posted, at least not in 20191.1 on Windows. Controls position is 20,20 on the window, mouse over the top left pixel of the control, me.mousex, me.mousey is 20,20

It is like removing the Resized event and telling you to keep track of the last size change in the resizing event.

Or as ilogic as saying that is useless to sell takeaway food because people can buy ingredients and cook it themselves “the result is the same so business with already prepared food are redundant” :roll_eyes:

Many people never reach out, others think that complaining is useless and others just walk away :expressionless:

1 Like

X and Y in the MouseMove event are relative to the control, but the MouseX and MouseY properties are window-based as of 2021r2.1 built-in documentation.

1 Like

apologies - my mistake.


So I guess I have to do some cybernetic calisthenics to be able to position a popup canvas relative to the mouse position instead of simple code like

cvTag.Left = Me.MouseX + 20
cvTag.Top = Me.MouseY + 8

Well in any other case it’s gonna waste CPU and perhaps for 99% of the controls it’s not even used if ever… maybe on the canvas (and your classes), but not on our (sub)classes (100’s of them).

i’m sure xojo can create a good example how to implement such yourself if you require to have mouseX and mouseY on each class. I know you already know how to draw, animate etc by your excellent classes/controls.

Can’t you save the mouse position to your own properties in the MouseMove event? Not too much calisthenics required.

1 Like

The X and Y passed to MouseMove are local to the control, not the window. MouseX and MouseY, when used in a control, referenced relative to the window. Interestingly enough, MouseX and MouseY still exist for a Window (relative to the window) and System (relative to the screen).

Many people never reach out, others think that complaining is useless and others just walk away

I too feel complaining is useless.
But in my opinion the Desktopnnn changes are superfluous and annoying.

But nobody asked for our opinion before the changes were made, and as seems to be the consensus, Xojo won’t want it now.
This is saddening.

Since Desktop controls are not compatible with mobile controls, having the mobile ones prefixed with Mobile already differentiated between them, no?.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.