Is there a way to select the SU selection tool?

I’d like to have a fallback that would jump to the selection tool in case of some fairly severe failure. Is that possible?

Sketchup::Model#select_tool() says:

The select tool is activated if you pass nil to the select_tool method.



There is also the non-preferred #send_action:


These “actions” are really meant for toolbar buttons or menu item commands, and act asynchronously just as if the user had clicked a button or fired a keyboard shortcut.

So prefer other API methods (when possible) especially if you need a return status from an action.
The #send_action module method only returns a boolean indication of whether it “knows” the requested action on a given platform, and does not block. (Ie, your next code statement could be evaluated before the application finishes doing all it should do for the requested action.)

Okay, let’s talk about in what situations you might think this is necessary.

Generally it is frowned upon to change the user’s tool choice unless they are expecting a change.

Also such change should only be done from an active Ruby Tool of your own design. This might be done for a “one shot” tool such as moving or stretching some object that was previously chosen with the Selection Tool.

It is also generally more acceptable to pop your tool instance off the toolstack so as to reactivate whatever the previous tool was.

More Info …

When something goes wrong, it is best to inform the user perhaps with a UI.messagebox and either allow them to try again, to cancel the operation, or reset the tool to it’s initial state.

1 Like

Pushing and popping the tool stack (at least in my mind) should only be done if your tool is changing the view, not modifying the model. Otherwise, I would think that you could get some strange behaviour when the tool attempts to do something that it was expecting to be there but is not anymore.

One reason that I wanted to change the tool to the standard selection one was because my tool expects that a component is selected prior to starting my tool. Currently, it displays an error message box and then continues on. I guess I can force my own selection to stop this issue from happening. I was just being lazy (well, to be frank, there is just a lot of stuff to iron out already and I didn’t want to bother).

Thanks for the UX Guidelines though. That’ll be helpful.

No. You pop the tool off the toolstack in order to do what it does, which has the effect of activating the previous tool, whatever it was. It is matter of etiquette. (ie, the “U” in GUI stands for “user”. It’s the user’s interface.)

This does not have anything specific to do with the view.

And a Ruby tool does not need to do anything crazy or weird to allow SketchUp’s built-in view manipulation tools to empower the user to change view in the midst of a custom tool.
These tools (Orbit, Pan and Zoom) operate in interrupter mode and suspend active tools.
All a tool need usually do is define the resume and suspend callback methods properly so that they can happily resume operation from the state where they were suspended by the native view manipulation tools.

Okay, but this is poor design practice.

What we encourage instead is that you attach a validation proc to the menu item (or UI::Command) that only enables the command or tool if the selection is not empty and it contains a component instance.

some_menu ="Plugins")
cmd_id = some_menu.add_item("My Task") { do_my_task_method_call() }
some_menu.set_validation_proc(cmd_id) {
  selset = Sketchup.active_model.selection
  if !selset.empty? && selset.single_item? &&

Yes I understand coding a picker is tricky. ThomThom had to create a whole guide on how do it.

What you could do rather than the validation proc is have a branching statement that implements your own picker state. (Ie, if a component is pre-picked, your tool would skip the picking state.)

You would need to implement a Sketchup::PickHelper object for your tool’s own pick state.

Its a matter of etiquette not to cause the application to crash or do random or not very intuitive things because it wasn’t designed to deal with cases that it shouldn’t have to deal with. Complicating the SW by taking into consideration nonsensical use cases is a waste of dev time and frustrates the user when things go aerie.

If you will notice with the pan, orbit and zoom tools (view changing tools), if you got there while you were using a tool that edits the model (editing tools), it will allow popping back to the editing mode when done, not back to one of its other the view modes (i.e. if you went from edit to zoom to pan to orbit, leaving orbit you go back to edit). There is no harm in doing so, but this makes sense as it would be a waste of the users time to go back through those other view modes when you really would rather be editing.

When going from a view tool to an edit tool, you cannot pop back to your view tool. There is also not too much harm in doing that as when done editing, the workflow would more likely be to edit something else, not changing your view.

However, when you are in an editing tool and you go to another editing tool, there is no tool that just pops back to the previous editing tool. There would be too much confusion on the user’s side. Just what does it mean to rotate and half way though that you decide to move, delete, stretch or do some other editing task. What would it then mean to go back to the previous editing mode, which in this case was to rotate? What are you now rotating? Why would you be rotating?

You can’t just blindly say that you must do only one thing because “It is matter of etiquette.” It’s a matter of usability, intuitiveness and being sensical.

I’m well aware, but there are certain priorities that I have to consider. Just like all SW design and implementation, you have to triage.

I actually agree and was dumbfounded when I read somewhere the suggestion that error boxes were a “preferred” way. I don’t remember where I saw it, but I do remember seeing it. I think the reasoning is that you can’t get any help information from a disabled control.

Yes, I will be getting to that eventually.

That was probably me mention that. By disabling UI elements it’s harder for a user to learn why it’s disabled. But if you rather provide feedback when a command is invoked in invalid pre-conditions there is an opportunity for the user to explicitly learn why.

I experienced this myself with one of my extensions where the original version would disable the toolbar buttons for when the selection was invalid. I got a constant trickle of users contacting me for support, wondering why the button was disabled. When I changed it to not be disabled and instead present a message explaining why they all went away.

Disabled items is a common convention that goes back a long time. But being a long time convention doesn’t mean they are ideal conventions in terms of UX.

Some related UX articles on this topic:

Why you shouldn’t include disabled interaction elements in your design system | by Chris Atherton | UX Collective (

Why You Shouldn’t Gray Out Disabled Buttons (

1 Like