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.
4 Likes
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…
-Karen
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”.
2 Likes
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” 
Many people never reach out, others think that complaining is useless and others just walk away 
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.
2 Likes
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?.
2 Likes
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 feedback://showreport?report_id=29359 and feedback://showreport?report_id=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