MouseCallback.OnMouseUp not called when an object is selected


(Menno Deij - van Rijswijk) #1
  1. Run the command below to start listening to mouse down and up events. Make some clicks left and right to ensure that the listener is enabled

  2. Select an object in the document.

Result: mouse down is raised, mouse up is not raised.
Expected result: first mouse down, then mouse up is raised.

private MyMouseListener listener= new MyMouseListener();
protected Result RunCommand(RhinoDoc doc, RunMode mode)
{
    bool enable = listener.Enabled;
    Result res = RhinoGet.GetBool("Enable/Disable mouse listener", true, "Disable", "Enable", ref enable);
    if (res != Result.Success)
        return res;

    listener.Enabled = enable;
    RhinoApp.WriteLine("The mouse listener is now {0}.", listener.Enabled ? "enabled" : "disabled");

    return Result.Success;
}

public class MyMouseListener : MouseCallback
{
    protected override void OnMouseDown(MouseCallbackEventArgs e)
    {
        RhinoApp.WriteLine("Mouse down for "+e.Button);
    }

    protected override void OnMouseUp(MouseCallbackEventArgs e)
    {
        RhinoApp.WriteLine("Mouse up for "+e.Button);
    }
}

Mouse up doesn't return Get(true)
#2

I’m having the same issue dragging a grip using the C++ library.
I need the MouseUp event to end a grip-is-moving state that started with the MouseDown event.

Looking forward to solutions or workarounds, tia.


#3

Yes this is killing us at Gemvision also.


(Dale Fugier) #4

Can I get an idea of why you are using this class and what you are looking to do? The reason I ask is this is almost never used in Rhino.

If you are looking to control the mouse from in side of the command, you should be using our standard pickers and getters (GetObject, GetPoint, etc).

You might not have much luck controlling the mouse or overriding Rhino’s default mouse behavior, when no command is active, as Rhino is in charge of all mouse messages.

Again, please provide me some details as to why you are using this class.


(Menno Deij - van Rijswijk) #5

In my case, I was hoping to bind a command (RunScript-ed) to the simultaneous left+right mouse button click, in order to speed up the workflow of using this command. So, whenever it is feasible to be able to run this command, the mouse callback would be enabled.

I was hoping to get each mouse-up and mouse-down event and set boolean variables on the left and right buttons being down. Whenever a mouse down event is encountered when for one button when the other button is not yet up, the command would be triggered. Unfortunately, due to mouse-up not being fired when a selection is being made, the booleans’ state is not reliable.

I would expect that whenever a mouse callback is active that all mouse events are reported, and not that some are selectively consumed. This way, the mouse callback is rather useless in my opinion.


(Dale Fugier) #6

My guess is that Rhino’s mouse code is eating mouse events in the event of mousing down/up on an object. I’ll take a look - might not much we can do about it…


(Menno Deij - van Rijswijk) #7

Ok, thanks. That was what I suspected as well.


#8

As for my case I am developing custom grip move behavior. The grip starts moving in the direction of the cursor if clicked close enough. I use the OnMouseMove to record the actual pointer position. This starts by setting a boolean value in the OnMouseDown and I was hoping to reset this in the OnMouseUp.
Although the current development seems not to be compromised I don’t like the idea of the OnMouseMove endlessly keeping updating the pointer position after finishing the custom grip move.


#9

Maybe a random thought but…

you can check what the last command is that you used. There is something like StartCommand and EndCommand. If you use the GripBehavior only for the move you can check when someone uses an other command than Move. If e.Englishname <> “Move” then Boolean = false.

Or check if your grips/your command ends and then boolean = false.

or something like that.


(Dale Fugier) #10

I’m assuming you are doing this because grips are either hard or don’t work in RhinoCommon?


#11

That’s correct. We were not able to use RhinoCommon for showing only surface control points in a single line in one direction. Also we mirror control points in a centerplane if they are behind a certain ‘dividerplane’. We do the same for e.g. isocurves on the surface.


#12

We are wanting this to work to make our F6 menu in Matrix more efficient and detecting what types of objects are selected.

We look at the document at the selected objects, and present different menu choices based upon what is selected.

Particularly when an object has PointsOn we need to be able to detect that a Grip is selected and then check to see if they are TSplines objects in order to filter our menu.

Currently I am using a timer to check the document after a mousedown event. Not pretty…


(Dale Fugier) #13

Hi Jason,

Sorry for being dense. But what does pressing F6 to detect selected objects have to do with “mouse down” detection?


#14

Sorry, I should have explained further. Pressing F6 in our software Matrix, brings up a Context Menu similar to right-clicking on an item in Explorer. It presents possible commands a user can do with the selected rhino objects.

This is becoming a more prominent feature / process within our software and we have enhanced the “menu” to show information about what is selected, weights, sizes, etc.

We now have a Pin option to the F6 menu, that keeps the window open and reacts to user’s selections.

But we have difficulty with Grips, so when Points are turned On we don’t get a Selection Event when we select a grip. So we are trying to at least react to the MouseUp event which never comes…


(Dale Fugier) #15

Thanks for the clarification, Jason. This really helps.

The “On Select Object” event watcher has always filtered out grips because (internally) the pointers to grip object are often deleted shortly after selection/deselection and (in the past C++) plug-in developers cannot be trusted to use object ids or serial numbers when watching an event and then dealing with the event later. Thus, if a C++ plug-in developer needs to see grips, they must use the newer CRhinoOnChangeObjectSelectState class.

Since the functionality behind this class is not exposed in RhinoCommon, I’ve added an item to our issue tracking system to add one.

http://mcneel.myjetbrains.com/youtrack/issue/RH-28669


#16

Thank you. Look forward to it.