WxWindows for SketchUp Dialogs

[Dan Rathbun]

@unknownuser said:

model_name=File.basename(model_path,".skp")

was model_name=File.basename(model_path) which was including extension of a SU file.

The Model.title method returns the basename (ie filename,) minus the file extension.

Note comparison:

model_name=File.basename(model_path,".skp")
Sketchup.active_model.title == model_name
# would return true

[thomthom]

@dan rathbun said:

The Model.title method returns the basename (ie filename,) minus the file extension.

Uh? is that something SU implements? don't see it in the manual...

[Dan Rathbun]

@thomthom said:

@dan rathbun said:

The Model.title method returns the basename (ie filename,) minus the file extension.

Uh? is that something SU implements? don't see it in the manual...

Woops.. sorry omitted the link. Here is is:
http://code.google.com/apis/sketchup/docs/ourdoc/model.html#title

[thomthom]

I'm going crosseyed. didn't see that. think I looked at Sketchup class when I looked...

[tomasz]

@dan rathbun said:

The Model.title method returns the basename (ie filename,) minus the file extension.

Thanks. I wasn't aware of the method.

[Dan Rathbun]

@unknownuser said:

Why Sketchup.active_model.name returns always an empty string.

ANSWER: It doesn't ALWAYS return an empty String, it always returns the value of the name attribute (which is class String.)

But IF you never set the value of the name attribute, then of course it will 'seem' to always be an empty value, because it is.

The value can be set easily using the Model.name= method.

Example Code:

n = Sketchup.active_model.name
n.inspect
#>> ""
Sketchup.active_model.name="A newly set name for my model."
n.inspect
#>> "A newly set name for my model."

IF you are writing plugins for other users, you should not expect the name attribute to always be empty, and should (in your code,) allow for those times when the model has been assigned a name value (by the user or another plugin.)

ALSO, in the Outliner Window, the model will be listed by .title value, NOT by the .name attribute.

P.S.: I can't find a edit control, anywhere in the UI that allows setting the .name (or the .tags) attribute. They SHOULD be on the 'File' page of the Model Info ToolDialog, but are not. (This forces us to use the Console to set the name or write a lil' script to make an inputbox.)

Edited: meant to say ' .tags' attribute instead of '.note'; a note is just a Text class object, and not a attribute of the Model.

[Malkomitch]

@unknownuser said:

Have you used the WxFormBuilder? It would be nice to have a straight output compatible with WxSU! There is a beta which works with Python.

Tomasz

or you can export your design to a xrc file (xml style) and load it with xml methods from the Wx module.

xml = Wx::XmlResource.get
xml.load(your_file.xrc)

(google for "xrcise", this utility write for you the code needed to load your xrc)

[Malkomitch]

@unknownuser said:

I would appreciate any help with solving this strange bugsplat which appears instead of a simple ruby error message in the console.
It happens after triggering an 'evt_button'.

It looks like WxSU doesn't handle errors communication between WxRuby and Sketchup.

The best way to get rid of bugsplats is to handle exceptions by yourself, at the end of each method that uses WxSU:
That way, you display the call stack, letting you know where the bug is.

rescue => detail
   puts detail.message
   puts detail.backtrace.join("\n")

[tomasz]

@malkomitch said:

The best way to get rid of bugsplats is to handle exceptions by yourself, at the end of each method that uses WxSU:
That way, you display the call stack, letting you know where the bug is.

Thanks a lot for your help.
I get a bugsplat when closing SU, but it is definitely better this way.
I though that begin ... rescue ... end is required, but I am glad to hear that rescue alone is sufficient.

Writing about xml loading I must say that I prefer to write my own Ruby code based on 'initial' FormBuilder layout, as it helps me better understand WxRuby. Thanks for hint anyway!

Tomasz

[Dan Rathbun]

@unknownuser said:

I thought that begin ... rescue ... end is required, but I am glad to hear that rescue alone is sufficient.

That is because in module definitions, the module statement is a block statement so the word module works the same as begin (after all, the module does need an end.)

module My_Module
  # method defs
  # code goes here
rescue
  # error handling code
else
  # only do code if no exceptions
ensure
  # always do this code on exit
end # the end of the method def

The same is true for method definitions, where the def keyword 'begins' the block.

def my_method
  # code goes here
rescue
  # error handling code
else
  # only do code if no exceptions
ensure
  # always do this code
end # the end of the module

[tomasz]

@dan rathbun said:

That is because in module definitions, the module statement is a block statement so the word module works the same as begin (after all, the module does need an end.)

Thanks for the explanation.