SketchupExtension in a single file

thomthom

I've not used the SketchupExtension class for plugins that didn't already require additional files as I didn't want to distribute simple plugins in multiple files just to make it work with SketchupExtension.

But it occurred to me today that you don't need to load a different file to use SketchupExtension, you can just load the same file that defines it. I posted a code pattern example here.

I'm changing my plugin template to use that pattern so my plugin in the future can be managed with, ... whatever managers we''ll have out there. I'm hopping for something better than the native manager.

Dan Rathbun

Interesting, no doubt. (Shows how flexible Ruby an be.)

Questions:

1)

The SketchupExtension class uses the following statement in it's load method:
success = Sketchup::require @path

Why does not this call see your file, already in the $LOADED_FEATURES (aka $",) array, (from it's first load on startup,) and prevent it from being loaded the second time ?

2)

What happens if the @load_on_start (2nd argument) to Sketchup.register_extension is true, and Ruby tries to re-load the file (at that point,) whilst it is still within the same file ?

I suppose at that point there not much left to process except to recognize the " else" and jump to the " end" of the " unless" block.

OK.. asking, made me realize: this will not work for both cases.

The answer to "2)" is that it will work, (when @load_on_start is true,) because the file's path has not yet been pushed into the $" array. So Sketchup.require will load the file, BUT it will ALSO push the file's path into $". THEN the first "instance" of the file loading, may also push the file's path into $", creating duplicate entries.
Although having dup'd entries may be considered sloppy, I don't think require() cares, ... one entry is all it takes to skip the load and return false.

The answer to "1)" has two cases, (the " true" I just answered.) If @load_on_start is false, the script exits (having registered the extension,) and pushes the file's path into $".
But if the attempt is made sometime later, (via a change in the Preferences>Extensions dialog checkbox,) it should fail, during that particular Sketchup session. (The default @load_on_start in the registry will be set true, however, and then it will work, on the next Sketchup restart.)

Now we have version differences between <8.0M2 and >=8.0M2, as the older do not have @load_on_start or @registered attributes. Add to that the Sketchup.register_extension method code was changed on the C side for 8.0M2 ...

You may be able to add in a complex SU version & $" check just after the Sketchup.register_extension call (before the " else",) ... but IMHO it is just overcomplicating things. Especially for the newbies to understand.

What if you could create a [ruby:1xrw0v4c]class[/ruby:1xrw0v4c] or [ruby:1xrw0v4c]mixin module[/ruby:1xrw0v4c], to which you pass a [ruby:1xrw0v4c]Hash[/ruby:1xrw0v4c] (of extension attributes,) that puts this complexity "out of site", and the script would just include the mixin, or instantiate the helper class ??

thomthom

@dan rathbun said:

But if the attempt is made sometime later, (via a change in the Preferences>Extensions dialog checkbox,) it should fail, during that particular Sketchup session. (The default @load_on_start in the registry will be set true, however, and then it will work, on the next Sketchup restart.)

Ah! I was testing by loading an external file - using load. So my initial load didn't use Sketchup::require. Seems that I need to pop the entry off the stack after registering the extension. Nice catch.

thomthom

@dan rathbun said:

Add to that the Sketchup.register_extension method code was changed on the C side for 8.0M2 ...

What was that?

Dan Rathbun

@thomthom said:

@dan rathbun said:

Add to that the Sketchup.register_extension method code was changed on the C side for 8.0M2 ...

What was that?

To much to explain.. you'll need to read the comments in the code. Scott marks what were the private callbacks from the C side.

But basically calling the method more than once in previous version has no benefit, screwed up the extension list in the dialog.
Now 8.0M2+, the method was changed to expect to be called more than once, and to do things, based upon the change in arg 2.

Dan Rathbun

One reason I am a bit adverse to this idea is, that I was hoping for a day when plugins resided within their author's filespaces, and the plugins directory had nothing but extension registration scripts. All code for actual functionality, would be in subfolders.

I like the idea, of being able, to switch off whole groups of plugins, by author is one way.

Jim

The @extension_registered variable is always false when SketchUp starts, so the menus will never be created after the first time the extension is enabled.

thomthom

@jim said:

The @extension_registered variable is always false when SketchUp starts, so the menus will never be created after the first time the extension is enabled.

Thought I'd fixed that...

Jim

Oh, I was just reading your blog and copy/pasted the code, but I never got the menu to appear. But then later I thought the code should work because SketchUp should go ahead and reload the file as an extension after initially registering. So not sure what's going on.

Dan Rathbun

Re-read my earlier post: http://forums.sketchucation.com/viewtopic.php?f=180&t=43200&#p384925

Your setting up a vicious circle.

Dan Rathbun

What about using a begin ... rescue ... end block to "fool" SketchUp.

Meaning set the path to a file that does NOT exist, which will raise a LoadError Exception.
(EDIT: ..and I think you can just use an empty string for path, in this case.)

begin
  # set up here
  plugin = SketchupExtension.new('Nifty Plugin','dummy')
  # set other attributes
  Sketchup.register_extension(plugin,true)
  # if it attempts to load, the rescue block fires
rescue LoadError
  #
  # A little code for a "quickie" Plugin here.
  #
end

Dan Rathbun

NO (the above,) will not work because Sketchup::require() and Sketchup::load() do not raise LoadError. They just return false on failure, and 0 on success.
(I do have a API bug report filed on this.)

thomthom

@dan rathbun said:

NO (the above,) will not work because Sketchup::require() and Sketchup::load() do not raise LoadError. They just return false on failure, and 0 on success.
(I do have a API bug report filed on this.)

They don't raise LoadError ...? That's interesting.

My mistake was that I tested the whole thing by loading manually from an external location instead of placing the file in the Plugins folder and having it load at startup. My "simulation" was incorrect.