Issues with set_attributes Method and Components


#1

For almost two years now I have been pulling out my hair trying to figure out why my start_operation and commit_operation in the truss module was throwing an error, see this thread:

I finally had enough with this (minor) bug and pulled apart my code and systematically eliminated everything until I came to this single block of code (which is the cause of the error):

da = 'dynamic_attributes'
t_def.set_attribute da, 'trussfamily', @Trussfamily
t_def.set_attribute da, '_trussfamily_label', 'TrussFamily'
t_def.set_attribute da, '_trussfamily_formlabel', 'Truss Family'
t_def.set_attribute da, '_trussfamily_units', 'STRING'
t_def.set_attribute da, '_trussfamily_access', 'VIEW'

With this block I am trying to set an attribute on the truss component using the dynamic attributes library. For some reason SketchUp does not like it and it makes the operation methods above blow up.

Alternatively I thought why not forego the dynamic library stuff and just try this:

lib = 'medeek_truss_eng'	
t_def.set_attribute lib, 'trussfamily', @Trussfamily

However, it does not seem that one can set attributes to a component definition, which is very frustrating.

I’m now looking for a way to set attributes to a component definition (without side effects), if this possible, but I’m coming up empty.


#2

Just a note that the Entity#set_attribute method is not the only means of setting attributes. (It is a actually a shortcut method.) So perhaps try other methods directly on the dictionary instance.

The other thing that occurs to me is you are setting the DC attribute value first, and then afterward setting up it’s properties. Try setting the value last after all the properties beginning with an underscore.


#3

I just tried this:

da = 'dynamic_attributes'
t_def.set_attribute da, '_trussfamily_label', 'TrussFamily'
t_def.set_attribute da, '_trussfamily_formlabel', 'Truss Family'
t_def.set_attribute da, '_trussfamily_units', 'STRING'
t_def.set_attribute da, '_trussfamily_access', 'VIEW'
t_def.set_attribute da, 'trussfamily', @Trussfamily

but I still get the error:

medeek_roof_truss.rbs:3198: warning: Ruby operation left open: "Draw Fink Truss"

What is the other method for accomplishing this same task?


#4

I told you …

So consult the API docs …

… and it’s instance methods …


Also, you may wish to check the API Issue Tracker about #set_attribute() causing a closure in undo operations. (There may be an open bug.)

You don’t give a complete example of how you are wrapping your undo operation.
BUT, I do note that what you see is not an error, … it is a warning generated by SketchUp.


#5

I’ve gone through my wrapping of the undo operation with a fine tooth comb, so to speak.

In the end I essentially stripped the entire program down, eliminating one chunk of code at a time until I arrived at the small section given above. Once I removed that chunk of code the warning went away.

I then compared my code for the truss module to the rafter module (which is not having this problem) and sure enough the section of code setting attributes to a component definition is not part of the rafter module.

I then reinstated all of my original code and removed (commented out) the offending section. When I run the plugin the warning is no longer generated so based on this I’m quite confident that the wrapping of my commit/undo operations are in good order and working at it should be.

It is just something about this set attribute business with component definitions that seems to be the problem. Unfortunately, I haven’t had enough time today to fiddle with it more but I will get to the bottom of it in the next day or two.

The good news is that it is just a warning and not an error so it is not the end of the world but at the same time I don’t want to be causing instability in SketchUp for the user with any of my plugins and it feels like it is doing this (even though it may not be).


#6

Are these Dynamic Components where the warning occurs?


#7

Yes Nick, as he showed above he is setting dynamic attributes via Ruby calls.


#8

I get the same thing so my current work around is to have users turn on “Animate Doors” in my configuration settings. This way Trimble passes my cabmaker and doormaker extensions. If I include DC attributes then Trimble fails my extensions.

If I set this in the Ruby Console:
Sketchup.debug_mode = true

Then I get these warnings like this
warning: Ruby operation left open: “CabMaker”
SketchUp: warning: Ruby operation left open: “Interact”

My ultimate test is when I load any DC - the same warning is issued. This includes DC examples that Trimble provides.

I see this as “the pot calling the kettle black”


#9

I guess I’m not going crazy after all. If someone has a way to set the DC attributes without triggering this warning please enlighten me. This particular problem does not seem to have a solution.


#10

It is likely caused by the DC observers reacting to changes you are making to a component.

You may need to use one of the transparent boolean arguments so that your undo operation is “attached” to the operation in the DC code.