DesktopCanvas does not get Matched Mouse Down and Mouse up events on macOS

Bugs and Feature Requests
1

Feedback Case Number: * #72007

DesktopCanvas does not get Matched Mouse Down and Mouse up events on macOS.
This issue affects many Custom controls also. (Same issue does not happen on old style Canvas class).

Its taken me long time to realize what is going on with various of controls that seem to have their clicking glitched in their Desktop version. But i finally pinpointed it.

  1. Run the attached example project on macOS.
  2. Double click the Red square (which is the canvas).

You will see emitted into the ListBox
MouseDown
MouseUp
MouseDown

But 2nd MouseUp was missing. (This of course makes it impossible for custom controls to draw states if they cannot keep track of if the mouse is up or down)

  1. Change super of the canvas from DesktopCanvas to Canvas.

You will see emitted into the ListBox
MouseDown
MouseUp
MouseDown
MouseUp

(as it should be)

2 Likes
2

The second MouseUp is consumed by the DoublePressed event. It’s a bit annoying, but easy to code around. Just treat DoublePressed as another MouseUp.

I was confused at first, too, but I’m not sure how else they’d implement it unless they followed suit and added a Pressed event and both acted independently of MouseDown and MouseUp, which I would prefer to the current functionality.

3

I guess they really should just let it call MouseUp internally first and then the DoublePressed event.

1 Like
4

Yeah, then you have the possibility of two DoublePressed actions (not raised events) resulting from a single Double Press as the user may handle one while the framework raises the other.

5

That would not happen, since Xojo only runs in one true thread.

You will never get event while code is finishing other event.

6

I would prefer Pressed and DoublePressed events that act independently of MouseDown/MouseUp.

7

No, I’m saying a user could code their own handling of DoublePresses by using Mouse events, and DoublePressed would still also fire. I think they were trying to avoid something that should’ve been made easier by separating the functionality.

8

It’s also unlikely that this behavior would change as it would silently break anyone’s code that relies on it being this way.

9

I wouldn’t think so. It would just fire an additional MouseUp. Code in DoublePressed to handle quick presses would still execute as per my outline on the issue.

2 Likes
10

I think Anthony is right there.

And also, most peoples code has not yet been ported to Desktop API, so this will brake their code when they make the jump. And even in new apps this creates bug, me finding it was in new Application, which again made me look in components I have and find the problem all over.

Further more then usually for code then missing MouseUp is more destructive than a MouseUp that the code did not expect. Since the missing one tends to leave the UI in limbo. (If not having counter measures as Anthony suggest above)

4 Likes