Detecting Gumball Mouse Events

As part of a plugin I’m working on we are using a mouse callback to implement an interface where clicking on custom plugin display objects selects corresponding objects in the Rhino document.

One tricky portion of this interaction is the Gumball: it looks like Rhino’s clickbox for the Gumball is actually slightly larger than the pixels themselves. In some cases, when the gumball is over some of this geometry, to our plugin it looks like the user clicked on the object behind the Gumball, but in reality Rhino treats the click as touching the Gumball, which is what we want – however we’d also like to avoid interfering with this interaction and not do any custom plugin logic in this case.

Is there any way within the MouseCallback interface (or in general) to detect whether a MouseDown or MouseUp event was treated as starting/ending a gumball interaction by Rhino, or to prevent an event handler from firing on Gumball interactions?

Here’s a picture of the case I’m concerned with:
gumball-near-clickbox

Alternatively (equivalently, for our purposes) is there a way to get the native gumball to draw in the display pipeline at the size of its clickbox’s thickness rather than its display one?

2 Likes


Would changing the size of the gumball help? It might be a bit of a fiddle, but it could help?

– cs

Hi @Dan_Cascaval,

Is there any way within the MouseCallback interface (or in general) to detect whether a MouseDown or MouseUp event was treated as starting/ending a gumball interaction by Rhino, or to prevent an event handler from firing on Gumball interactions?

did you manage to find a way of detecting mouse interaction with the gumball? This would come in very handy in the plugin I’m working on now.

I wish!

In our plugin, we use CaptureToBitmap on a Mouse click event to draw the entire view to a system Bitmap object. Before we do this we turn off nearly every setting and try to draw as little as possible besides the gumball. Then once we have a bitmap we try to detect whether we’re near the gumball by looking from the mouse coordinate around the nearby area to find if any of the nearby pixels are the same color as the Gumball.

The gumball cover when hovered or nearby is determined by FeedbackColor in AppearanceSettings – if this is black, we set it to be a color that is visually close but not exactly black, which makes it a little bit more reliable.

This approach works, but it is slow, super hacky, might be the cause of some rare mystery crashes(!), doesn’t work well when the user is external monitors that are set to a different resolution than their windows primary display (because this may cause Rhino not to draw the gumball!), and can yield false positives if something in the user’s model is the same color. (The display thing can be fixed by setting the external monitor as the primary display, then everything works fine…)

Basically: we’re still doing it and we’re still going to do it, but I can’t really recommend the approach as a “proper” solution. If you go this direction and find a way to improve on it, I’d love to know - it’s been a long journey.

Is there any way within the MouseCallback to detect whether a MouseDown or MouseUp event was treated as starting/ending a gumball interaction by Rhino, or to prevent an event handler from firing on Gumball interactions?

@stevebaer would you be able to weigh in on this?

https://mcneel.myjetbrains.com/youtrack/issue/RH-81819/Detect-mouse-over-gumball-in-mouse-callback

I handed this to Joshua since he’s been working on the gumball quite a bit lately

2 Likes

Thanks guys. @Joshua_Kennedy, now that you’re at it - it would be great if we were able to track the position of the gumball when in drag mode. Currently there is no way for developers to know what is happening inside of the default display conduit activated when users interact with the gumball.

PS @Dan_Cascaval, hats off for pulling off this hack! But as you say, I’d stay away from implementing it in my plugin :slight_smile: