Execute UI.messagebox when a tool is deactivated or on 'onReturn'



I have developed a tool that allows users to select a few surfaces and then perform some calculations on them.

When the user either deactivate the tool or hits Return, I would like to show a message with the results of these calculations.

tool = RG::Aoi::PickSurface.new

The tool is defined as follows

module RG::Aoi
  class PickSurface
    attr_reader :results

    def activate
   other events

The problem that I have is that UI.messagebox is executed immediately after the tool activation and the tool cannot be used until I click OK. This means that tool.results is of course nil. The tool is activated within a callback from webdialog if that counts.

I guess I could save the results of the calculation in a file and read the file later, but this would require the user to perform another action.

Is there a better solution? Can tools be used in this way?


The first example is synchronous, that means a line of code blocks execution until it is finished and only then the next line can be executed.

However the lower example is asynchronous. A tool does not freeze SketchUp, instead SketchUp calls event handlers whenever an event happens, and inbetween the tool does nothing.

Selecting a tool waits until the tool is marked as selected, it does not wait until the tool is deselected. What you need to do is to pass to the tool instance an (optional) callback that the tool will call in its deactivate event handler.

class MyTool
  def initialize(&callback)
    @callback = callback # Store it in an instance variable for later use.
  def deactivate(view)
    @callback.call(@results) if @callback # You have saved results in an instance variable in another method. If no callback given, it may be nil.

MyTool.new{ |results|


Why a custom tool? Why not just perform the action on whatever was selected using the select tool?


Because the calculations are handled by separate classes and modules and I would like to keep them separate. The purpose of the tool is just to extract data from some surfaces selected by the user. This is then passed to the ‘calculator’.


That does not exclude the possibility of keeping aspects/responsibilities separated. Your technical code should be given e.g. entities or attributes, and you could have UI code that cares about extracting these from the current user selection. I agree, selection is better not directly used in technical code.

In any case don’t try to rebuild something that already exists (if your tool really does just selection), because you will loose focus on what is important and a self-made Select Tool will likely never be as powerful and well-tested (bugfree) as SketchUp’s native tool.


It works. Thanks!


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