Hi guys,

I believe there may be a bug (or incorrect implementation) with the Sketchup class load method. My understanding of the Sketchup class load method is that it is modeled after the Ruby Kernel load method but designed to handle scrambled files (.rbs) as well as non-scrambled files (.rb). The problem is that it doesn't seem to behave the same in that the Kernel.load method will load a .rb file even if it is already loaded - with the appropriate warnings - wereas the Sketchup.load method does not; even when executed from the Ruby console.

For example:

Kernel.load 'cabwriter_factory_settings.rb' results in

C:/Users/Joe/AppData/Roaming/SketchUp/SketchUp 2015/SketchUp/Plugins/cabwriter_factory_settings.rb:17: warning: already initialized constant CabWriterFactoryInitialize::NEW_PROJECT
C:/Users/Joe/AppData/Roaming/SketchUp/SketchUp 2015/SketchUp/Plugins/cabwriter_factory_settings.rb:17: warning: previous definition of NEW_PROJECT was here
true

Whereas Sketchup.load 'cabwriter_factory_settings' results in

false

Am I missing something or is this a bug?

@driven said:

@thomthom said:

What should "1w" represent?

chosen at random, maybe 1*width or 1 womble
john

I'm with you John. I calculate all my dimensions in wombles.

@tig said:

Why not take your normal 'numbers' text as your lengths, and then use key-down checks for toggling what it means ?
Like Cmd/Ctrl, Shift etc *** - so on one press of that key it expects one type of value [shown in status-bar] on the next press it's something else = i.e. it's a 'toggle'.

***You can use TAB key action as a toggle BUT it must be key-up as the MAC doesn't recognize tab-down - only tab-up !

Hi TIG,

That is exactly what I will end up doing in my tool. So as far as I am concerned I have a solution to the problem I raised, thanks to the folks like you who responded to my original question.

However, I think the bigger issue here is that there are scripts in this thread that work on the Mac and not the PC, and scripts that work on the PC and not the Mac. Apparently the Mac is not aware of the String class to_l method and the PC doesn't handle the h shortcut key correctly. Although I would argue that the PC is handling the h shortcut key the way I would like it to and the PC and Mac are handling shortcut keys when they shouldn't be if the VCB is active for user input.

I for one just wish that release 2013 spent more time on bug fixes, platform inconsistencies and Ruby API maintenance than it did on icon changes which are driving me nuts and causing me a lot of work.

But again, thank you and the others who helped me on this issue.

@chiefwoodworker said:

But your code is clearly more correct and you may have saved me a Mac bug. Very interesting that it works on the PC but not the Mac.

Whoops! Let me correct myself. SketchUp has a String def called to_l so the you don't need the to_f. Are you sure it doesn't work without the to_f?

@driven said:

Hi Joe,
your script partially works on mac with to_f added @ line 4.

Interesting John. On my Windows PC I modified the script as follows:

<span class="syntaxdefault">def onUserText</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">text</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> view</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    puts</span><span class="syntaxkeyword">(</span><span class="syntaxstring">"Text is a #{text.class} class."</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    begin<br />      value </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> text</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_l<br />      puts</span><span class="syntaxkeyword">(</span><span class="syntaxstring">"Value is a #{value.class} class."</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    rescue<br />      </span><span class="syntaxcomment"># Error parsing the text<br /></span><span class="syntaxdefault">      UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">beep<br />      puts </span><span class="syntaxstring">"Cannot convert #{text} to a Length"<br /></span><span class="syntaxdefault">      value </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> nil<br />      Sketchup</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">set_status_text </span><span class="syntaxstring">""</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> SB_VCB_VALUE<br />    end<br />    return if </span><span class="syntaxkeyword">!</span><span class="syntaxdefault">value<br />    if </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">state </span><span class="syntaxkeyword">==</span><span class="syntaxdefault"> 1 and </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">stick_pt2</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">valid</span><span class="syntaxkeyword">?<br /></span><span class="syntaxdefault">      build_story_stick</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">true</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> value</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      new_stick<br />    end<br />  end</span>

and get the following puts to the console. No complaints of coercing String to Length.

Text is a String class.
Value is a Length class.

But your code is clearly more correct and you may have saved me a Mac bug. Very interesting that it works on the PC but not the Mac.

@thomthom said:

I looked further at the behaviour of the Tool class - using variations of this snippet to inspect the behaviour:

thomthom,

Your help is well above and beyond anything I could ask for. Thanks again. I am loading the snippet to complete the "etc" and see if there are keys I can use.

@thomthom said:

I asked the SketchUp team, and they confirmed that onUserText enables the VCB - and enableVCB? is there to let you disable the VCB when you do not want user input. (For instance - if your tool uses the VCB to adjust values then you don't want the VCB to be enabled until you have performed an action.)

And enableVCB? is queried on certain event which one can assume the tool changes state - such as on mouse clicks.

thomthom,

Thanks very much for the help on this and clearing things up. The documentation on this is really poor and misleading. I still wish we had a way to disable shortcut keys like the native tools have.

Thanks again.

@thomthom said:

It's only a simple property to enable or disable the VCB.
The docs only says:

The enableVCB? method is used to tell SketchUp whether to allow the user to enter text into the VCB (value control box, aka the "measurements" panel). If you do not implement this method, then the vcb is disabled by default.

So it doesn't affect what types of characters you can input - it just enables/disables the control as a whole.

I don't think it is the onUserText that is enabling the VCB. I think the default is true, not false. Try this script:

class MyTool def enableVCB? UI.beep end end; Sketchup.active_model.select_tool( MyTool.new )

Depress and release the left mouse button slowly. You will see that enableVCB? is called on both the down and up of the left mouse button. That's why I think it is intended to sample each key stroke, to see if a shortcut key was preceded by a number, in which case it would be interpreted as a parameter of the number and not a shortcut key. But it doesn't get called at all with a key stroke, including the Enter key, which I think is the bug. Why is it called with a mouse action? That's what's curious to me.

@tig said:

It doesn't exist...
Just made it up - from what I know works...

I like your style

@tig said:

The excepted characters that are OK after a number are:
",',m,mm,cm,s,x,/,*,[,],<,> etc
Can you use some of those in your custom inputs...

TIG,

Where in the documentation did you find this list of accepted characters after a numeral? I haven't been able to locate it.

@thomthom said:

I'm puzzled that you can get a tool to accept VCB input if enableVCB? is not implemented... did you try my bare bone example?

I modified your example as follows:

class MyTool def onUserText(text, view) begin value = text.to_l #just to do something rescue # Error parsing the text UI.beep puts "Cannot convert #{text} to a Length" value = nil Sketchup::set_status_text "", SB_VCB_VALUE end return if !value UI.messagebox(text) end end; Sketchup.active_model.select_tool( MyTool.new )

I typed 36 into the VCB and hit Enter. Resulting output is shown in image at bottom.

@thomthom said:

What Windows version do you have?

Windows 8 64 bit.

@thomthom said:

And I don't think that enableVCB? is meant to be called on each key stroke.

Well, if it is supposed to allow and check for accepted characters besides numerals I would think it would have to. But it should at least be called on Enter and it isn't.

@thomthom said:

I cannot reproduce this...

> class MyTool; end;
> Sketchup.active_model.select_tool( MyTool.new )
> 

Any chance you've already loaded the code with enableVCB? ? Because then commenting out will not remove it if you reload the file.

Here is the sequence on my Windows PC.

1. Comment out the enableVCB? method.
2. Open SketchUp.
3. Open my model.
4. Select my tool.
5. Pick first point.
6. Type a number into the VCB with no characters.
7. Press Enter and the number is interpreted as a length by my conversion code.

I can repeat this sequence with only steps 6 and 7 changed.
6. Type a number followed by t, no space, and the Tape Measure tool come up.
7. Never get to step 7.

If I repeat the sequence using s in step 6. instead of t I get a system beep indicating the input can't be parsed (I don't have the code in there to parse an s).

Now I repeat these same three tests with the enableVCB? method coded to return true. Note I completely close SketchUp, make the code change and Re-Open SketchUp. I Don't use reload.

I get exactly the same results as with no enableVCB? method. Further, as I mentioned earlier, if I code the enableVCB? method as follows:

def enableVCB? UI.beep return true end

I never get a beep on any keystroke. But I do with left mouse button presses (and I believe left mouse button up as well). There is a bug here someplace but I am not sure how it should work. I know how I would like it to work, but that is probably not interesting to the SketchUp team.

p.s. I get the same behavior on SketchUp Pro 8.
p.p.s. I have a friend who wrote a tool script and never knew about enableVCB? method, hence never implemented it. His tool worked as long as what he typed into the VCB was numbers and no characters. If confirmed for me that he gets the same results I do when he uses a shortcut key. He then implemented the enableVCB? method to return true and also got the same results.

@thomthom said:

Without enableVCB? you cannot make VCB input...

And I've made use of s in VCB input - but it cannot be the first character to be typed.

I am using SketchUp 2013 Pro Windows version. I can comment enableVCB? out and still enter data through the VCB. However, if I enter 5s it invokes the Scale tool. I haven't tried Make or version 8.

@tig said:

The excepted characters that are OK after a number are:
",',m,mm,cm,s,x,/,*,[,],<,> etc
Can you use some of those in your custom inputs...

Unfortunately I don't think s works either; it invokes the Scale tool. The larger problem is that enableVCB? appears to have no effect on the VCB. You can leave this method out altogether and the VCB works the same way, i.e. the default false is not the case. In fact, I have confirmed that SketchUp does not call enableVCB? on any keystroke, including Enter. However, it does call enableVCB? on left mouse button. Go figure!

@tig said:

Have you set the enableVCB method to ' return true' ?
if not if returns ' nil'.

.......

When the user types 60t is the 60 appearing in the VCB - before the pressing of the ' t' jumps elsewhere?
Do you ever get to them pressing <enter> ?

Thanks for the response TIG. Yes, I have implemented the following:

# For this tool, allow vcb text entry while the tool is active. def enableVCB? return true end

just as it appears in the API documentation. If I type 60 followed by Enter everything is fine. If I type 60 and immediately type t upon depressing the t I switch to the Tape Measure tool. I never get to Enter in that case.

By the way, I modified the enableVCB? method as follows:

# For this tool, allow vcb text entry while the tool is active. def enableVCB? UI.beep return true end

and I get a beep whenever I press the left mouse key, but not when I type 60t into the VCB.

I am wrestling with a problem using the Tool methods. I have a tool where I wish to use the VCB to change some parameters of an object being drawn. For example, when using the Circle tool you can type 60s into the VCB and this changes the number of sides to 60 instead of the default 24.

In my tool I would like the user to be able to type 6t to change the thickness of a wall or 96h to change its height. In native tools like the Circle an entry of the VCB does not invoke a shortcut key i.e. 60s does not select the Scale tool. But in my tool, even though I have implemented the enableVCB? method, 6t invokes the Tape Measure tool and 96h invokes the Pan tool. I thought enableVCB? was supposed to force SketchUp to listen to the VCB when onReturn is fired, and not the keystroke when depressed.

Has anyone run into this? Is there something I am missing? I have discovered that I can leave the enableVCB? method out altogether and the VCB works just fine so long as I don't use a shortcut key. It seems to do nothing.

@adamb said:

@chiefwoodworker said:

I am done on this subject. I have gotten this off my chest and I am going to do useful work.

Probably for the best as you haven't actually articulated anything but a few grumbles. You do know, nobody actually develops using the Ruby console.. We use an IDE like Visual Studio or Xcode or Eclipse.

"Integrated with Rails." Are you insane? Why would you inflict a molasses-slow, bloated 'experiment' on a CAD package? Why? Just bonkers!

"The Ruby API may be dead in favor of the C++ API. ... I hope I am wrong, but that is the flavor of this release." Nobody has said that, you're just hearing what you wish to hear.

Can I just say "Bonkers" again. Ah, thats off my chest.

Gee, isn't that sophisticated. Visual Studio, Xcode, Eclipse. Well I use RubyMine IDE. Sorry if my choice of IDE doesn't live up to yours. And have you ever heard of Unit Test and Developer Console, a console that might have replaced Console if not pushed aside by EW? You might ask thomthom about it.

Do you know what Rails is? Are you aware that it would have nothing to do with rendering performance any more than WebDialog does, and it would certainly be more stable and useful than WebDialog. Bloated? Experiment? You might want to explain that.

Of course no one at Trimble has said the Ruby API is dead. That would be suicide. But if you read between the lines with the last two major releases you have seen no improvement in it, and if you look at the business Trimble is in you might conclude there is no need for it either.

You can say "Bonker" all you want. You live in a free society.

@thomthom said:

@chiefwoodworker said:

My point exactly, although I will go one step further. We had this capability with the SCF store. Trimble wasted good SketchUp developer resources by reinventing the wheel [...]

SCF Store was released a couple of weeks before SketchUp's release. Clearly they'd been developed in parallel. That's hardly reinventing the wheel. Should they have just cut the feature because SCF solution was released marginally earlier?

No, it should never have made number one or two priority of things that made the list to be included in the 2013 release in the first place. There were much more valuable ways to spend resources.

thomthom, I am really at a loss to understand why you and other "almost SketchUp development team members" are being so protective of this release. We stand no chance of getting real improvement in SketchUp if people like you aren't willing to push back on Trimble. You have my admiration for the help you have provided me and other developers over the years, but you and the influential others should be honest with Trimle. This release is a joke, and to increase the price of SketchUp in the face of this joke is the height of arrogance.

It is curious to me why you guys have to be out in front protecting Trimble when there seems to be no Trimble people (short of Chris who has been a member of the team for only a short while) here listening to users concerns. Are you really pleased with this release?

@unknownuser said:

Not everything should be imposed to Trimble's Extension Warehouse

My point exactly, although I will go one step further. We had this capability with the SCF store. Trimble wasted good SketchUp developer resources by reinventing the wheel and called it a major feature addition to SketchUp when what they should have done with those resources is something else altogether, like give us the Developer tool, fix bugs in the API, fix compatibility problems between the Mac and Windows versions etc. Instead we got a crappy release and have to wait another year to see if SketchUp is going to evolve as the tool we had always loved.

I really am done ranting on this release now. It is a complete disappointment, but I will wait a year and see what Sana Claus brings. Off to do some real work.

@adamb said:

What concretely is it that you were expecting of this release?

What concretely do you think Ruby 2.x is going to give SketchUp?

I don't believe I ever said the 2013 release ought to have been Ruby 2.0. If I did I stand corrected. What I believe I said was that there should have been some movement in the right direction.

I'll answer you question specifically in a moment. But here is an indisputable fact: SketchUp without a Ruby API is a toy and has no significant commercial value. The developers showed genius in three areas. They kept SketchUp strategically simple so that it was easy to learn and use. They provided a Ruby API to allow users to plug holes in any particular are of use. And they set a price point (and later a free point) that made it easy to adopt. I suspect they knew what they were doing when they made the Ruby API the jewel of SketchUp.

Fast forward and we see two major releases of SketchUp that doesn't address the jewel in any way; nor does it address the ease of developing plugins for SketchUp and neither does it improve functionality, performance or bug fixes that the user can see (they may be there but they don't seem to be visible yet). This seems like a cardinal sin to me.

I have wanted some help for developers in debugging and testing code. Quite some time ago I and others suggested integrating Test Unit into SketchUp. When I saw the beta Developers Tool (which I now make extensive use of)I was so happy I could wet my pants. Then 2013 came out and not even a hint of test and debug help.

The Ruby Console is next to useless. There have been several plugins to work around it that have been helpful. You can't clear the Console, enter multiple lines of code or reload a script. Again, Developer tool hinted of going in that direction, but alas no help.

Why, after the last two major releases of SketchUp, are the Mac and Windows versions of Ruby interpreter still different? Is it because the SketchUp team likes to see the third party developers fix their code when they get different results on different platforms?

There are numerous API method bugs that have been outstanding for some time (e.g. observers onSelectionBulkChange and onSelectionCleared). I haven't checked yet to see which are solved and which are not, but it is a sign of the problem that Trimble has not published what problems have been resolved in this release. It's up to the users to test for fixes.

Because the Ruby API is the crown jewel of SketchUp it would be nice if there were a long range road map for it. And even nicer to see an incremental step on that road map. Wouldn't it be nice if we woke up to a major release in the future where Rails was also integrated into SketchUp and the WebDialog would be history. And we might have database support. Further, wouldn't it be nice if some IDE like RubyMine understood, or was at least aware of, SketchUp Ruby class and method extensions? You can't get there if you don't take a step in that direction.

What I read into this release is that Trimble has a plan for SketchUp, but long term I doubt the large majority of plugin developers is going to like it. The Ruby API may be dead in favor of the C++ API. The free version of SketchUp may be completely decoupled from SketchUp and may itself be eliminated. I hope I am wrong, but that is the flavor of this release.

I am done on this subject. I have gotten this off my chest and I am going to do useful work.