Detect that SHIFT is down


Say I have an extension with 6 toolbar buttons.
Each calls a different method to transform the preselected objects.
(No SketchUp “tool” is involved.)

Now I want to implement an “enhanced” mode for each of the six.
I could add six more buttons. (UG!)
I could ask the user in a InputBox (UG!)
I’d rather have the enhanced mode activate if the user is holding shift down before he clicks on the button.

But onKeyDown and VK_SHIFT only work within a “tool”.

So maybe I can create a simple tool called at the beginning of each button method, just to return the shift status maybe as a @@variable.
It has to detect that the shift is already down!
It has to return to the calling method without any action by user!

Anybody think this can be done?
Seems like any API should allow this, but maybe not.


I have never ever seen an application where toolbar buttons act in different modes depending on modifier keys. The reason must be that this is very uncommon, and probably no Human Interface Guidelines in the world recommend this.

An alternative in SketchUp would be to have a toggle button (pressed/not pressed). For example Inkscape’s Line Tool has toggle buttons for Bezier/Spiro/B-Spline/Straight/Axis-parallel modes (on a context-sensitive toolbar). If it however significantly changes the meaning of your six buttons, it would not be any better than the above.

If you want to do the work-around with a temporary tool to get the modifier key:
SketchUp actually uses a tool stack. Usually selecting a tool removes the previous tool from the stack (thus the stack has a length of 1). But you can push a new tool to the stack and later return to the previous tool. Keep in mind that old versions of SketchUp used to crash when popping the last tool from the stack (when the stack is reduced to 0).
Since you can keep a reference to the tool instance, a simple instance variable (with accessor method) is enough, no need to use globals or class variables.


A toggle button might be good. (similar in concept to caps lock) And I can toggle the icon.
I agree that no application GUI that I know of follows this approach, yet the most common UI of all (the keyboard) does!
I’m not supporting versions before 16 because of lack of encryption.
But even with a temp tool, I don’t see how I can determine that the shift is ALREADY down.
Tools can only detect onKeyDown.


I have seen applications that do different things depending upon which mouse button the user clicks the toolbar control with. The most common is a settings popup (ie, a non caption dialog box) when the right-mouse button is clicked on a toolbar button or control.

I would not mind if the SketchUp API added handler proc methods (mouse button callbacks) to the UI::Command class for toolbars. The current constructor proc is fired on LMB click. Ie on_left_click(), on_right_click(), on_middle_click() and on_double_click(). They could be changed “midstream” but this should only be allowed from the file that created the command object (for security reasons.)


I’m going with Aerilius’s idea of a toggle button.
That way it’s in the user’s face so he remembers that there is an enhanced mode. Also I can switch out all 7 icons with each toggle.


You can ? Does this work cross-platform ? (Never tried changing the button icons before, myself.)

(I remember that changing the tooltip text went away when the tooltips were overhauled for v2013+. That used to be handy to change the tooltips.)


I have tooltips that I change depending on context.
I’m on Windows 7.
Never tried swapping icons.
But I just left for vacation and don’t have computer access.
Back in 2 weeks.
Meantime it should be easy for you to try it.


I am not speaking of the statusbar text. We can no longer (since 2013+) change the tooltips that pop up next to the cursor. Once set for a command object, they cannot be changed (unless you are using native platform system calls.)


Watch this video.
Following 11:30 it shows tooltip changing.



##! An error occurred during validation.
###This video does not exist.

Sorry about that.


Double sorry.

  1. Somehow last letter got lost when I pasted the link. I
  2. But the point is moot. I now remember that when mouse hovers over a toolbar button, the status bar text strangely appears BOTH in the lower left status bar AND below the tooltip text. So its only the status bar text that can be changed. But it serves the pupose of acting tooltip.


I tested it, and I see it does work whilst a tool is active. This is good news!

I probably saw it failing (in the past) when trying to change tooltip outside of an active tool. But testing this also now works, although I swear (scout’s honor) that this was failing in the past at some version.

(I’ve discovered what the confusion is, … see below.)

Actually we both are confused, because the API documentation is poor, and does not explain well what happens when you use one of tooltip or status_bar_text and not the other. When only one is used, SketchUp makes assumptions that are not described in the documentation. This has likely led to the confusion.

If you use status_bar_text that is set before or after the command is added to the toolbar, it will always override the tooltip property and you cannot thereafter dynamically change the tooltip description. This is what led me to believe that tooltips became static from 2013 onward. (In fact, it is the implementation that has issues.)

Anytime you set the status_bar_text property it will override the tooltip property until the status_bar_text property is set to an empty string.

If you do not use status_bar_text but only tooltip you can dynamically change tooltip description text to your heart’s content, but you can never have any status bar text on v2013. (This I would characterize as a bug, as it is unwanted behavior.) This must have been fixed (although I cannot find it listed as being done in the API release notes,) as it does not occur on v2014 or newer, the tooltip property will appear on the status bar, IF status_bar_text property is not used.

So the two properties are intertwined in a weird way that is not intuitive.

Tooltip_Test.rb (1.5 KB)

It is also weird that the tool title is taken from the initial setting of the tooltip property, instead of the menu_text property setting. (This then requires a double call to the tooltip=() method. One before adding the command to the toolbar, and one afterward.) The value set before is “set in stone” as the tooltip title when the command object is first added to the toolbar, but thereafter changes to the tooltip property will be used and rendered to the tooltip description area (instead of status_bar_text.)


none of it works on a mac…

you only see the first for each tooltip…

no status bar text, but that not there even when is coded…



Disappointing … Oh my platform parity, where art thou ?


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.