[Plugin] TT_Lib²
-
Thanks TIG!
That superscript 2 has caught many off guard.
"Nobody expects Unicode multi-byte characters!"
-
Oddly the superscript 3 in your 'Cleanup' name works just fine.
It's only seems to be the superscript 2 !
But then even 178.chr fails too...I already knew that names including a ' or starting with '#' messed up in the ruby/js/callbacks...
I have also now found that names ending in a <space> also mess up !
But they are all trapped now.
-
huh! That's very odd, as I'm sure that superscript 3 is in unicode as well... :s
-
Tell me about it...
The characters in Extension names that mess with ruby/js/callbacks in webdialogs when passing js-side RS joined [RS = String.fromCharCode(30)] arrays, that are then then split at RS [RS = 30.chr] ruby-side, to give the individual names, are:[pre:1yxha6nn]<space> at the end of the name
at the start of the name
' [single-quote] anywhere in the name
² anywhere in the name[/pre:1yxha6nn]It doesn't matter if that is Unicode or ASCII 178.chr
Other superscripts etc like ³ do not seem to cause issues at all...I have a series of traps to stop issues now - these will be in an upcoming release [aka 2.5.0]...
-
In the end, you have found the problem of TT_Lib² in Extension Manager
-
@oxer said:
In the end, you have found the problem of TT_Lib² in Extension Manager
You can still manipulate that Lib [for now] in the native Extensions panel.
I'd always leave it 'enabled' anyway...
A new version of the SketchUcation Toolset, including the updated Extensions Manager and lots of new goodies, is in alpha-testing now - sliding into beta-tesing soon - and then v2.5.0 will be released - probably early in the new year ?
-
Now the bad news...
After further testing... I confirm that my fix for a superscript 2 in the Extension's name doesn't work with TT_Lib² after all... It was a spurious result...
It must be something to do with the way the file calls itself - almost unique amongst Extensions !
Then I noticed that Fredo's Lib uses a fake Extenson...#Compatibility with EWH begin ; SketchupExtension.new "toto", "toto.rb" ; rescue ; end
That is all, and that gets past the EWH check and does NOT register an Extension ?
Although through other means there is an entry fro LibFredo6 ?? ...So the fix seems to be in TT's hands.
Simply remove the current 'extension making code' and add in a 'fake file' like as shown above, and it works... there's no 'fake extension' confusing users in the Preferences OR the SCF Extensions Manager...
-
That's odd. How is PluginStore determining if a plugin is enabled/disabled?
By the way, are you doing string manipulations? Passing a Ruby multibyte string, encoded in UTF-8, should work fine as long as the HTML is marked up in UTF-8 as well. JS handles UTF-8 by default I think as well. So simply passing strings back and forth should not be a problem.
-
HTML is UTF-8 - there is no issue the superscript 2 was a dead end...
The Extensions Manager uses the obvious :
` Sketchup.extensions.each{|ex|
next unless ex.respond_to?(:registered?) && ex.registered?
...
if ex.loaded?
...
else ### unloaded
...
end}`
etc
Fredo's Lib uses the spurious file ans has no issues.
Calling itself seems to break it.
I substituted the equivalent of Fredo's one liner in your 'loader, it doesn't register an extension BUT it does still let the Lib be used... -
Updated TT_Lib 2.9.5 will fix the issue.
Download from PluginStore or BitBucket:
http://sketchucation.com/resources/pluginstore?pln=TT_Lib
https://bitbucket.org/thomthom/tt-library-2/downloadsSubmitted to moderation on Extension Warehouse.
This should address 3D Text Editor's issue with IE11 and hopefully appear correct to PluginStore.
-
Thanks Thom for fix the problem!!
-
The update does fix the 3d text font list problem...
BUT...
On PC and MAC I now get this issue whenever SketchUp starts
@unknownuser said:Error Loading File C:/Program Files/SketchUp/SketchUp 2013/Plugins/TT_Lib2/core.rb
uninitialized constant TT::System
Error Loading File TT_Lib2.rb
uninitialized constant TT::System
One step forward one back.Also you have not fixed the issue of a 'mock Extension' like your Lib calling its own file, which breaks the listing in the SketchUcation 'Extensions Manager' dialog, where it always appears disabled, even though it is enabled.
As I explained before... Fredo gets around it by loading a non-existent 'toto.rb' file in a begin...rescue, and NOT registering it at all, which means an spurious Extension is not listed - so it should not appear in the Extensions list ?
You have now stopped it calling itself, BUT now load [and register] 'core.rb', which exists in the Lib's folder, but that now creates errors too... why not put it in a 'begin...rescue' block and refer it to a file you DON'T have in your TT_Lib2 folder - like 'foobar.rb' - and do NOT register it, then no Extension is made and no one is confused at all...
This edited code works for me### EXTENSION ### ------------------------------------------------------------ unless file_loaded?( __FILE__ ) # This library is still loaded by plugins because they require # 'TT_Lib2/core.rb' directly. # Disabling the library via the extension manager # will have no effect on the dependant extensions. # # The purpose of this file is solely to make it compatible with the # Extension Warehouse policies. file_loaded( __FILE__ ) begin ex = SketchupExtension.new( PLUGIN_NAME, 'TT_Lib2/foobar.rb' ) #ex.description = 'Library of shared functions used by other extensions.' #ex.version = PLUGIN_VERSION #ex.copyright = 'Thomas Thomassen © 2010-2013' #ex.creator = 'Thomas Thomassen (thomas@thomthom.net)' #Sketchup.register_extension( ex, true ) rescue end end
the Lib is loaded by other tools, it is NOT made into an Extension, so there is NO confusion at all...
-
@tig said:
Also you have not fixed the issue of a 'mock Extension' like your Lib calling its own file, which breaks the listing in the SketchUcation 'Extensions Manager' dialog, where it always appears disabled, even though it is enabled.
Huh? I changed to to load core.rb ...
I didn't want to use a dummy file as I wouldn't trust that to not display an error.
-
@tig said:
You have now stopped it calling itself, BUT now load [and register] 'core.rb', which exists in the Lib's folder, but that now creates errors too... why not put it in a 'begin...rescue' block and refer it to a file you DON'T have in your TT_Lib2 folder - like 'foobar.rb' - and do NOT register it, then no Extension is made and no one is confused at all...
The real fix here is to figure out where the error is coming from. I don't want to patch the symptom, I want to fix the cause.
-
I'm not able to reproduce the TT::System loading error...
-
I get it on PC & MAC v2013...
Unless I re-jig you code to use the nonexistent foobar.rb and NOT register the extension anyway...
Then it's all OK.
-
Does it happen with a clean Plugins folder?
-
@unknownuser said:
Error Loading File C:/Program Files/Google/Google SketchUp 8/Plugins/TT_Lib2/core.rb
uninitialized constant TT::SystemError Loading File TT_Lib2.rb
uninitialized constant TT::System
With nothing except "TT_Lib2" loading from Plugins [and only the 3 'required' rb's in Tools - sketchup. langhandler and extensions] - error happens in both basic v8 [PC] & v2013 [PC & MAC]...
But oddly 'another version' doesn't display the issue at all ?Incidentally, this one simple change to your script stops these error message...
**#**Sketchup.register_extension( ex, true )
There is no need to register the mock-Extension as it is doing nothing, and other tools will load what they need from it anyway... -
Thanks for the reports TIG. I'll dig into it. I need to make some emergency patches for that other version anyway as well.
-
One odd thing I noticed is a circular 'require' in two of your rb's ?
In
core.rb
[which 'loads' first from the extension code load]...
require 'TT_Lib2/system.rb'
In
system.rb
which has been called by core.rb...
require 'TT_Lib2/core.rb'
So maybe the
TT::System
isn't initiated properly and the error occurs [with Ruby 1.8] ?
The require of the core.rb should skip if the code is already loaded, BUT maybe the extension load doesn't register in the list in the same way, and a second attempt occur with an error message...
Advertisement