RhinoCommon Rhino.Commands.Command routing


I’d like to cancel a command already started from the keybindings of native Rhinoceros application, before it executes its purpose.
In my specific need I’d like to abort a delete of selected geometries requested from the press of the canc keyboard key, in a similar way to RoutedEventArgs.Handled of .NET Framework routing of keyboard or mouse devices.

Is it possible?

Hello @cavalli.stefano,

I’m not sure what you’ve asked is exactly possible. I don’t know that you can abort a command, but you can always undo something. But this is flimsy. I’m going to provide this solution, although it’s a bad idea for several reasons.

// Register your event
Command.EndCommand += OnEndCommand.Event;

// The Event
internal static class OnEndCommand
			case "MyCommandName":

I’d be curious to know what you’re trying to prevent as there is probably a much better way of solving this.

I’d like to skip the delete command of native Rhinoceros command set.
The Delete command removes from the RhinoDoc all the selected RhinoObjects, and the situation after the execution is not the one expected from the plugin memory state, considering its internal reasons to keep in that moment the selected geometry in the RhinoDoc.
The undo is an option, but it creates new ids and it uses computing resources.

Hi @cavalli.stefano,

There isn’t a good way to cancel a command that was initiated by the user. Your plug-in will need to work within this framework.

– Dale

Hi @dale ,

This kind of feature could be managed by giving the access to the keybindings table of all the commands, maybe only for a plugin skin different from the empty one? I tried to find the place to change the keybinding of the canc keyboard key to the _-Delete Rhinoceros native command, but I have not found this optional setting.

Now I have to detect the geometries deleted from the canc keyboard press, and exit from the plugin.

An alternative strategy would be to subscribe to the RhinoDoc’s DeleteRhinoObject event and then act accordingly.

1 Like

Hi @Travis,

following your suggestion a solution could be the recreation of the rhinoobjects from the desired memory state?
My actual guidelines to avoid these situations is hiding the layer/group native tables and act accordingly with RhinoObjects and RhinoGroups, creating blocks with no external references.

Yes, the delete objects event will tell you which objects are affected and you can act from there on restoring their states.

Ok, thanks for the synchronization.