SketchupExtension path question

david.

The API doc's for SketchupExtension.new say the path is the relative path to the script to be loaded. Is this only allowed to be a relative path? Or, can an absolute path be specified? I guess I can try it to see if it works. Maybe someone already has?

I'd like to register my extensions, but I don't use the SU plugins folder to organize my plugins. I use a single autoloader script. That's the only script that I copy to the SU plugins folder. BTW, I don't hard-code paths but I do use a common convention. I know that's not how anyone else organizes their plugins (that I know of). I do it this way to keep my plugins separate from SU's or other plugins. It also allows me to easily archive the files on my non-system drive. I don't like to keep user files on the system drive with applications and the OS (Win 7).

thomthom

Feed it an absolute path if you want - I do. I make the loader make a full path based on __FILE__.

Dan Rathbun

@david. said:

The API doc's for SketchupExtension.new say the path is the relative path to the script to be loaded. Is this only allowed to be a relative path? Or, can an absolute path be specified? I guess I can try it to see if it works. Maybe someone already has?

Actually the @path attribute of the instance, expects a String object (which should be a pathstring to an existing file, but the class itself does NOT test to be sure it's a valid filepath)!

The instance's load() method in turn calls Sketchup::require( @path ), so it's that module method, that determines what the path argument can be (or not be.)

The standard require() method (defined in module Kernel, and inherited by all objects,) FIRST checks to see if the path argument resolves to an absolute path, BEFORE it begins going through the $LOAD_PATH array, checking for valid relative paths.

Sketchup::require() in some aspects, does NOT act the same as Kernel::require(), and so I, personally avoid using it and Sketchup::load(), except for loading rbs files.

And.. I have filed bug reports on the variant behavior of both methods, but ... I don't expect them to change the methods.

david.

OK, thanks. Good to know.