Yes, and I’ve told Cayden previously not to use UI::Notification objects.
They are not designed to be used for workflow prompts (and their display time cannot be controlled [yet.])
Cayden should use normal modal messageboxes instead.
(Cayden, FYI, modal means that the messagebox or dialog seizes the focus and does not release it until the user dismisses the window.)
With regard to the SketchupExtension object, it’s registrar file is a separate file that goes in the “Plugins” folder. All your extensions other files go in a subfolder that has the same name as the registrar file.
If the extension registrar file is "CaydenWilson_ProTrim.rb" then your extension subfolder must be named "CaydenWilson_ProTrim".
The handles are not an issue because your code is not using them.
The most prime rule for coding in a shared ObjectSpace is that ALL YOUR CODE MUST be within your toplevel namespace module (ie, the CaydenWilson module in the above example,) and any code specific to a CERTAIN EXTENSION should ALL be within that extension’s submodule (in the example the CaydenWilson::ProTrim submodule.)
Even the lonely …
require "sketchup.rb"
… method call can be within your modules. It is a frivolous call because the SketchUp engine loads it (and the other "Tools" subfolder files "extensions.rb" and "langhandler.rb") during the startup cycle ever since the release of SketchUp 2014. These loads happen before any extensions ever begin to load.
You do not “run” code like this (ie, a module definition) repeatedly in an event-driven programming environment. Instead the module is loaded at startup and waits for an event to fire off the display of the inputbox.
The event will be the user either choosing a command from a menu or clicking a toolbar button. So this means you need a “eval once” block at the bottom of your module that creates the UI elements (your extension’s submenu and /or toolbar and the command objects that will be attached to the menu items and toolbar buttons.)
if !@loaded
submenu = UI.menu("Extensions").add_submenu("ProTrim")
cmd = UI::Command.new("Build Trim") { build_trim_command() }
submenu.add_item(cmd)
# Set the @loaded var to true so this block is only evaluated ONCE:
@loaded = true
end
Such a block that evaluates only once, will prevent multiple submenus, menu items and toolbars, etc., from getting created, if you tweak your code and need to reload it during development.
Reference class documentation for:
So as shown in the eval once block above, you need a command method that will be fired by the user when they start your command. I called it "build_trim_command()"but you can name it what you like.
Put the inputbox code inside this method.
Also I’ve told you repeatedly, you must always check that the return value from the input box is “truthy” (ie only two things in Ruby are falsehoods and these are false and nil. Everything else evals booleanwise as a truth.)
So this means that if the user cancels the inpubox then the variable input will eval as a falsehood.
If the user enters values (or accepts the default values) and clicks OK, then input will be an array instance and eval as a truth, so your subsequent code can go ahead and treat it as an array of values.
A simple one liner inserted just after the call to UI.inpubox would be …
return unless input
It tests that input evals as true (and therefore cannot be false or nil,) and so must be an array instance. If the user has cancelled the inputbox, your code should assume the user wishes to cancel the command, and so the return statement will exit the method, and nothing will happen.
Some extensions do display a “Command Cancelled” messagebox, just so the user knows their cancel has worked and they know nothing in they model changed. (Your code, your choice.)
Lastly, in order for your methods to call each other without qualification, you need to extend the module with itself. Put this statement at the top of the module.
extend self