More tool confusion


#1

There must be some dumb thing I don’t understand about defining a tool.
Here’s the simplest tool I can imagine but it doesn’t work:

All I try to do it make VCB available to enter text. then puts text to ruby console.
I have a puts in each def to see what is triggered.
When I execute, I’m not able to enter into VCB.
All that appears in console is these 4 lines:

initialize
deactivate
activate
Sketchup::Model:0x0000000c217e90

Here is the code:

module Testtool

class PutTool

	def initialize
		puts "initialize"
		Sketchup.vcb_label = "enter text"
	end

	def enableVCB?
		return true
		puts "enable VCB"
	end

	def activate
		puts "activate"
	end

	def deactivate(view)
		puts "deactivate"
	end

	def onUserText(text, view)
		puts "onusertext = " + text
	end

end # class 
puttool = PutTool.new
Sketchup.active_model.select_tool(puttool)

end # module

#2

The following works for any numerical input (incl. multiple values delimited with the platform list separator.)

If any keyboard accelerator letter is pressed your tool will be deactivated, and the other tool will be activated.

Even trying to return false from key callbacks, does not suppress SketchUp’s desire to select new tools.
(This has been a long standing thorn in the developer’s sides.)

module Testtool

  class PutTool

    def initialize
      puts "PutTool: initialize method"
    end

    def enableVCB?
      puts "PutTool: enableVCB? callback"
      return true
    end

    def activate
      puts "PutTool: activate callback"
      Sketchup.vcb_label = "Enter text"
      Sketchup.status_text = "Type text and press [ENTER], to see it echoed in Console."
    end

    def deactivate(view)
      puts "PutTool: deactivate callback"
      Sketchup.status_text = ""
      Sketchup.vcb_value = ""
      Sketchup.vcb_label = "Measurements"
    end

    def onKeyDown(key, repeat, flags, view)
      puts "PutTool: onKeyDown callback"
      puts "  key = #{key}"
      puts "  repeat = #{repeat}"
      puts "  flags = #{flags}"
      puts "  view = #{view}\n"
      return false
    end

    def onKeyUp(key, repeat, flags, view)
      puts "PutTool: onKeyUp callback"
      puts "  key = #{key}"
      puts "  repeat = #{repeat}"
      puts "  flags = #{flags}"
      puts "  view = #{view}\n"
      return false
    end

    def onUserText(text, view)
      @input = text
      puts "PutTool: onUserText = "<< @input.inspect
      Sketchup.vcb_value = ""
      return @input
    end

  end # class
  
  @@puttool = PutTool.new if !defined?(@@puttool)
  
  UI.menu("Plugins").add_item("Put Tool") {
    Sketchup.active_model.select_tool(@@puttool)
  }

end # module

#3

Gosh! Well I thought I was doing something simple. Guess not.

Thanks for saving my life again.

Barry Milliken, Architect


#4

OK that works.
Please define " platform list separator."
and by "keyboard accelerator letter " I assume you mean “shortcuts” defined in the Sketchup Preferences??


#5

Ah… got me. I meant "parameter, not “platform.”

The character used to separate values in parameters lists. It varies from locale to locale. In the US it is the comma. But in Europe where they use metric the comma is the decimal separator, and they use semi-colon to separate values in lists.

Yes, but the term “Shortcut” on PC, is a link (`.lnk*) file that has a URI property meant to open websites, storage locations (disk directories,) and applications.

The proper term is “keyboard accelerator”.
https://en.wikipedia.org/wiki/Accelerator_table

… but yes people use the two terms interchangeably.


#6

I’m starting to realize the implications of this:
Since its so easy for a user to inadvertantly deactivate a tool, any command method that calls a tool must do so on it’s final line before the method end statement.
Anything after it (such as “model.commit_operation”) might not be processed.
So, such steps must be included within the tools own methods.

PS: I hadn’t realized until now how many single letter shortcuts (no ctl or alt) are loaded by default.
I had assumed they all had to be user defined.


#7

It is very “out of the ordinary” for one tool to select another. Usually selecting a tool is a manual user activity.

Command object can select tools in their proc, but then these are usually attached to toolbar buttons, so the activation is caused by manual choice.


#8

If I’m not mistaken the deactivate is always processed when a tool is somehow deactivated. This is the place to cleanup, abort/commit operations and ensure that your plugin is left in an consistent state.


#9

I was referring to a user who by mistake keys a shortcut letter into the VCB.

I do sometimes use ‘Sketchup.send_action “selectSelectionTool:”’ at the end of a command so user is set to select objects.

In the case of the tool I’m now developing:
-tool performs a rotation on multiple objects using the current default angle.
-the user is given the option to enter an angle into the VCB to override what has just occurred.
-if he does, the rotation is reversed, and redone using the new angle.
-He can override again an number of times within the tool.
-the angle he enters becomes the new default.

I had expected the “reverse” to be a simple 'Sketchup.send_action “editUndo:”'
but since I’m inside a tool, I’ll have to do an inverse transform on each object instead.


#10

This interface may go away in the future. Every chance team members get they discourage using it.

In this case you can use:
Sketchup.active_model.select_tool(nil)
which will activate the SelectionTool.


#11

Yup, that happens. But also more often we want that same letter to be a tool specific sub-command. But some other tool gets activated instead.


#12

Then I’ll at that point need to update my current extension and advise all users to download.

Just to more fully explain my tool: I’m creating a tool because its the only way I can get user input of a single value to the VCB instead of a modal inputbox. That’s all I need it for.
I would have hoped there was any easier way without all the complexity and weaknesses of the tool class.

With inputbox I could have at least parsed and rescued what the user enters, asked him to try again etc.
It’s a tradeoff. After I see how the tool works I may revert to inputbox.