User ending a program

ktkoh

I have used "exit" in my joint tool program for cases where the user's selection was in error or when a data form asked for input that the user did not have so they selected cancel. I do see that this produces an error message in the ruby console so I am asking if this is unacceptable practice? I found that if the space bar is pressed the selection tool is activated and my tool dropped but Sketchup.send_action "selectSelectionTool:" does not do anything.

Keith

Dan Rathbun

@ktkoh said:

I have used "exit" in my joint tool program ...

Is this an external script running in a system Ruby process, or a SketchUp extension running in an embedded Ruby subprocess ?

Raising a SystemExit exception has only good use in a system Ruby script, and no good use in an embedded Ruby subprocess.

So, yes, within SketchUp, it is poor practice. It is better to raise a RuntimeError exception with a custom message, or create your own exception subclasses within your extension namespace.

Here is a simple example:
Custom_Exception_SubClasses.rb


# encoding ; UTF-8

# A simple example of creating your own Exception
#  sub-classes inside your own namespace modules.
#
# fail() is an alias for raise(), and most coding style guides
# prefer that fail() is used when first causing an exception,
# and raise() is used when re-raising a current exception within
# a rescue block.

module Author # <--<<< Change to unique toplevel namespace module.

  module SomeParticularPlugin

    VERSION = '1.0.0'
    
    InputCancellation = Class.new(RuntimeError)
    InvalidSelection  = Class.new(RuntimeError)
    NoGroupsSelected  = Class.new(RuntimeError)

    # In this module we assume that the module variables; @@prompts,
    #  @@defaults, @@choices & @@caption have already been defined.

    def get_input(selection_set)
      
      # First, make a decision about the selection set;
      if selection_set.empty?
        fail(InvalidSelection,"selection is empty!")
      elsif !selection_set.single_object?
        fail(InvalidSelection,"selection not single object!")
      else
        grps = selection_set.grep(Sketchup;;Group)
        if grps.empty?
          fail(NoGroupsSelected,"no groups are selected!")
        end
      end

      data = inputbox(@@prompts,@@defaults,@@choices,@@caption)
      # false if the user cancels
      fail(InputCancellation,"user cancelled") if !data
      # otherwise data is an array of values

    rescue InputCancellation => err
      UI.messagebox("Stop; #{err.message}")
      return nil
    rescue InvalidSelection => err
      UI.messagebox("Selection Error; #{err.message}")
      return false
    rescue => err # any other exception
      # recover gracefully
      UI.messagebox("Error; #{err.message}")
      return false
    else # no errors
      # code to execute when input is valid
      return data
    end ###

  end # specific plugin module
end # outermost namespace module

ktkoh

Thanks Dan that really helped me. I had never run across the term fail() and was able to research this in the ruby help files I use. I have tested it in my program and find it works as you described.

Keith

Dan Rathbun

@ktkoh said:

Thanks Dan that really helped me.

Cool! That was the purpose.

@ktkoh said:

I had never run across the term fail() and was able to research this in the ruby help files I use.

Kerenl#fail() is just an alias for Kernel#raise().
(I explained this in the file comments, and why I use it, instead of raise.)

@ktkoh said:

I have tested it in my program and find it works as you described.

I just noticed an error, although the example should still work.

Line 38 was meant to be:
data = UI.inputbox(@@prompts,@@defaults,@@choices,@@caption)

Currently it is:
data = inputbox(@@prompts,@@defaults,@@choices,@@caption)
which uses the global inputbox() retry wrapper method defined in " %(black)[Tools/sketchup.rb]". So then the " %(black)[sketchup.rb]" file must be loaded first.

If y'all prefer, you can call the UI.inputbox() module method directly and bypass the retry wrapper.

Dan Rathbun

So, you realize that although you could handle this scenario with very long cluttered if ... elsif ... else constructs, likely with a bunch of nested if statements,... that would be hard to maintain and use more lines.

This way condenses the code, and makes it more readable, and easier to maintain.

ktkoh

The program I used as a model when starting used that method. However as I added more functions it became almost impossible to find how to get out to the end of the mouse click down def.

Keith