Thanks TIG. Have not gotten very advanced with Classes etc. so just a simple module. Appreciate the explanation.

Thanks TIG. I though @@ was for classes???

I got an "uninitialized class" error until changed @@obs to @obs

Your solution worked perfect though!

Is there any way to check to see if an entity already has an observer attached to it?

I am using:

class MyInstanceObserver < Sketchup;;InstanceObserver
  def onChangeEntity(entity)
	  #puts "onChangeEntity; #{entity}"
  end
end

and then

my_openings = ent.grep(Sketchup;;ComponentInstance).find_all {|oi| oi.definition.name.include?('OPENING') }
  my_openings.each do |oi|
    next unless oi.valid?
  oi.add_observer(MyInstanceObserver.new)
end

But would prefer not to blindly attached an observer always. This loop will have been run previously.

Dan, that is genius. Thank you.

I think this

g.name = 'MY_TARGET_GROUPS'

needs to be changed to

g.name == 'MY_TARGET_GROUPS'

Right? It changed set all group names rather than testing for equivalence.

Anyway, grep with a more complex block seems like such a more efficient way of getting objects than getting an array then looping it to test for certain properties, then looping THAT array to test for others, and so on... which is what I felt like I was doing before. This will be really helpful generally.

And got it about the 2 spaces... Just didn't paste in from Dreamweaver cleanly but will do!

Perfect Dan - Thank you. That was a two for: next unless item.valid? will be so helpful too.

BTW, I tried @variables and skipping the first element as shown below and it worked!

ent.grep(Sketchup;;Group).each_with_index do |item, i|
    next if item.name!='MY_TARGET_GROUPS'
	if i < 1
		puts "skipping first iteration for item; #{item} | #{i}"
		@first_one = item
	elsif i == 1
		@first_union = @first_one.union(item)
		@subsequent_handle = @first_union
	else
		@result_union = @subsequent_handle.union(item)
	end
end

So the @variable was "remembered" as TIG explained to me here which seemed to be what I needed.

Now I just have to streamline the iteration BEFORE the loop because this method uses an index that can't see the next if item.name!='MY_TARGET_GROUPS' check. If I have 10 groups and only 3 of them qualify, the index will be off and I might save the wrong @first_one. If I could get grep to do a Group check AND a name check, I could iterate with an accurate index. Can grep be passed multiple patterns in one call?

Thanks @pcmoor I see what you are saying...

The WALL DC has only dumb objects in it with no parameters.

The OPENING DC has sub objects that use parameters.

But this seems insane! You mean, the second you take advantage of parameters for your sub-objects you loose the ability to have central command of your DCs?!!!

Perhaps you can explain your modeling techniques more? So you have a DC you copy around a bunch of times the explode it? Doesn't that kill any link you have to the original definition?

Hello. If you want to union multiple solids programmatically, how would you do it? With the union tool (Tools > Solid Tools > Union [Pro Only]) you pick one solid, then another but can continue to pick solids, adding to the Union Result. Using #union(group) however, I am having trouble keeping a handle on the union result in order to continue adding to it.

If I do

union_result = group_a.union(group_b)

I can't seem to refer to union_result when I try to run union again for subsequent objects.

Here is the total picture that may provided more insight...

Disclaimer: this seems like a dumb way to do this but, because when I loop through all my target groups, I need something to union the first one with, I am creating a small dummy group like so...

mod = Sketchup.active_model
ent = mod.active_entities

# create a dummy object for initiating union
dummy_face = ent.add_face([0,0,0],[1,0,0],[1,1,0],)
dummy_group = ent.add_group(dummy_face)
dummy_group.name = 'DUMMY GROUP'
dummy_face.pushpull(1,true)

Then here is the actual iterating (WARNING - BUG SPLATS!):

ent.grep(Sketchup;;Group).each_with_index do |item, i|
	next if item.name!='MY_TARGET_GROUPS'
	if i <= 1 # first run so union with dummy
		union_temp = item.union(dummy_group)
		union_temp.name = 'TEMP_RESULT'
	else # subsequent runs can union with prior union result
		union_final = item.union(union_temp)
		union_final.name = 'UNION_RESULT'
	end
end

I also tried using entities[-1] for the last created entity and that ALSO BUG SPLATS:

union_final = item.union(ent[-1])

Perhaps there is something I am misunderstanding about iterating that "clears" the variables created during each loop? Do I need a global or something using the @ designation?

Also, instead of using a dummy object, perhaps I should just skip the first group - but then I would need a handle to be able to refer to it during the next iteration?
Your thoughts would be appreciated.

Hello All,

I was saddened to find out that a Dynamic Component (a door) I have been working on is duplicated and/or made unique when I change one of its parameters such as width or height. A quaint #n is added onto the end component name to mark the event. This really stinks because it means my ability to push changes to multiple DC instances from a single definition is effectively lost every time I change an instance's parameter.

To put it in concrete terms, say I start a project with a certain 8 paneled door DC. I design the whole project, setting various doors to different heights and widths, and the client decides they want single panel doors, or doors with circular windows, or scrolls, or whatever on them. I can't push that change to all the doors! This seems to defeat the whole purpose of components!

HOWEVER, I also have a wall component that DOES NOT seem to exhibit this behavior! I can have 10 walls in the model, all set to different widths, and they ALL remain linked to the original component definition. I can go into that wall component and add a column or whatever random shape and it shows up in ALL the instances!

So what gives!!??

As a test case, would anyone take a look at the attached file, make changes in the Component Options for each and watch the Outliner panel as you do so. Do you see the same result?

What is it about the two DCs that make them behave differently? Are there certain "rules" that the wall DC follows that the door DC does not?

Test File

@unknownuser said:

There was a lot of debate about this before launch. We wanted DCs to follow the rules of SketchUp as much as possible. So the question became: "If I have 3 DCs in a model, and I scale one of them, should all of them update? Or should only the one I scaled?"

...In the end, we thought it would be more frustrating to have every instance in the model update instead of just the one you scaled.

We've talked about adding some kind of toggle that would allow you to choose which behavior you prefer. Any thoughts on that? Do you guys think we did it backwards? I'd love to hear your ideas.

No, you didn't do it backward or forward, you just didn't work it out at all. The only logical solution would be to scale the one DC WITHOUT BREAKING THE LINK TO THE ORIGINAL COMPONENT DEFINITION.

It is essential to design workflow to be able to go back and make changes to ALL elements throughout a project in a quick and centralized way. As budgets change, design options are accepted/rejected/marked up, and products enter or leave the market, the ability to edit a single entity and broadcast that change to all instances in the model could save hundreds of production hours.

I am actually really surprised to discover that this is how DC work and the whole scheme is actually intentional. I am not a programmer but I don't understand why this could not be fixed? User Defined attributes can already feed sub-entites data, like LenX for a certain sub-group can be set to the User Defined attribute "MyLength" so why should it matter if one DC has "MyLength" set to 20 when another is set to 30? I must be missing something here?

Revit and AutoCAD have this ability baked into Families and Dynamic Blocks already. The both use dimensional constraints and user-defined parameters to set the contextual "data" of an entity and objects within can be set to react to that context in different ways.

And I think a "Component Replacer" is more of a band-aid approach than an actual solution. If it could be written as a 3rd party script (I believe ThomThom already did), it would have to not just reset the definitions of all the bastardized components, it would have to note and re-create ALL of the attributes of every component in the model so that all the scaling, visibility, etc. of various components would not be lost in the re-writing.

Please tell me this has already been worked out in SU2017 or something and that is why there has been no further dialog on it!

Same here. That changing the properties of a DC makes a unique component that is "de-linked" from the original component defeats the whole purpose of using components in the first place! You might as well just use groups.

Has any figured out a workaround or anything on this? ...seems like this issue has been around a while.

@sdmitch: That was it! Thank you - makes sense now. Much appreciated!

@TIG: Thank you for the detailed explanation!

@sdmitch: Thank you. This worked mostly, successfully copying the groups out to the model, however the transformations did not seem to make it. Of the 3 test "WALL" components in my file, one group was the correct size but moved, the other two were the wrong size AND moved.

Also,

ent = @mod.active_entities

returned undefined method `active_entities' for nil:NilClass so I changed it to

ent = mod.active_entities

to get the script to run. Am I missing something about the @? Which I think means you are calling an "instance" variable?

@Dan Rathbun: Thank you. I am just using the layer as an easy selector for the groups I want within the component. Do you recommend another way?

Hello All,

First off, sorry this is long-winded. I've found it hard to find other discussions on this (at least one's a mere mortal like myself could understand) hard to come by. Hopefully this will help someone else too!

Let's say you have a component definition called "WALL" and within that component you have 3 groups, each on their own layer. One of the groups is on a layer named "WALL_PRIMATIVES"

Now, say you have 3 instances of that component in a model, all with various locations, scales, etc.

What I would like to do is go into each component instance and copy the group on the "WALL_PRIMITIVES" layer to the root model context (I think this would be called Sketchup.active_model).

So, I have been able to successfully grab the target group using 2 the methods below, but neither one preserves the transformation (location, scale, etc.) of the group. Instead, what happens is that the copied groups end up in a position derived from the original definition, not the various instances they are pulled from.

Both methods use...

mod = Sketchup.active_model
ent = mod.entities

failed method # 1 - COPYING THE GROUP:

mod.definitions.each{|d|
  next if d.image? || d.group? || d.name!="WALL" # skip images, groups, and any component not named "WALL"
  d.entities.each{ |wall_primative_group|
    if wall_primative_group.layer.name == "WALL_PRIMITIVES" # only proceed with groups on target layer
        group_copy = ent.add_instance(wall_primative_group.entities.parent, wall_primative_group.transformation)
    end
  }
}

failed method # 2 - COPYING THE FACES:

temp_wall_primitives = ent.add_group # create an empty group to receive faces

mod.definitions.each{|d|
  next if d.image? || d.group? || d.name!="WALL"
  d.entities.each{ |wall_primative_group|
    if wall_primative_group.layer.name == "WALL_PRIMITIVES"
      wall_primative_group.entities.each{ |wall_primative_group_entity|
        if wall_primative_group_entity.is_a? Sketchup;;Face
		  puts wall_primative_group_entity
          new_face = temp_wall_primitives.entities.add_face(wall_primative_group_entity.vertices)
        end
      }
    end
  }
}

I think this has to do with iterating through definitions rather than instances per this discussion. However, if I try to iterate through the actual instances placed in the model, I cannot figure out how to even get to the target group. See the ERROR or PROBLEM comments in the code below...

ent.each{ |all_ents|
  if all_ents.is_a? Sketchup;;ComponentInstance
    next if all_ents.definition.name!="WALL"
    #puts all_ents.definition.name
    #all_ents.entities.each{ |all_comps| #ERROR; undefined method `entities' for #<Sketchup;;ComponentInstance;0x007fb00ab02b08>
    #all_ents.each{ |all_comps| #ERROR; undefined method `each' for #<Sketchup;;ComponentInstance;0x007fb00ab02b08>
	all_ents.parent.entities.each{ |all_comps| #PROBLEM; just pops me back to the top level because the parent is the model!
	  puts all_comps.definition.name
    }
  end
}

Please help!

Sounds like just what I need mariocha. Any updates? Could you post your rb?

Well that stinks. Is there any way to test for an error. Will Jim's solution work?

I'd like to be able to hide a group within a component based on the value of a text list variable (OPENING!TYPE) users select.

Here is the IF clause I am using for the groups "Hidden" attribute:

=IF(find("SINGLE",OPENING!TYPE),FALSE,TRUE)

Which says "If the string "SINGLE" is found in the attribute value for "OPENING!TYPE", return FALSE making the group not hidden, otherwise return TRUE making the group hidden.

The problem is that FIND() returns a number for where it found the search string. That is fine for when it successfully finds the search string because any positive number evaluates to true. BUT when it does not find it, it returns something like

Not found; SINGLE

Which does not evaluate to FALSE.

So, how can I use FIND() to return TRUE or 1 if it finds the search string and FALSE or 0 when it does not?

Thank you.

OK, I think I figured out what was causing the problem. When you type double quotes into the dynamic component (at least in Sketchup for Mac) the double quotes are sometimes changed from " to “ causing the formula to throw an error.

Thanks nonetheless for your help Jim!

Thanks Jim. I have no idea why but my original code is now working! SU did not like the quotes around the OPENING!TYPE reference but something in adding the quotes reset the field and made it read properly again.

I experienced this same glitch on 4 other groups I had to update in the component so it was no a fluke. I'll keep an eye out and if I can figure out what happened exactly, I'll let everyone know.

I'd like to have a particular group within a component be hidden based on one of the component's variables. For example, if you set the variable "TYPE" to "DOUBLE", I'd like to hide certain groups. However, this formula is not working out:

=IF(EXACT(OPENING!TYPE,"DOUBLE}"),FALSE,TRUE)

It is not accepting "DOUBLE" as a valid comparison argument.

Any thoughts?

I also think this is a great direction to push SU. I am an architect with some marginal IT and programming experience who loves SU. The beauty of working in Sketchup is the ease with which objects can be created. It is not unlike actual sketching in that, with a few simple strokes, you can evaluate and critique your design. The problem from a production standpoint is that Sketchup is a dead-end. Once you've got the design just right and the client has seen and approved the various views of the model, then you get to start all over from scratch with a traditional 2D drafting program or BIM modeler. The best you can hope for is that you can export a few section slices or a dumb 3D model as the startpoint. Either way, all your Sketchup proficiency and modeling gymnastics only got you to the beginning. What's worse, the disconnect between documenting a design and displaying it means that any refinements made during documentation aren't reflected in the original Sketchup model. Thus, subsequent changes requiring a client presentation will probably send you back to an out-of-date Sketchup model.

Essentially, SU is missing the documentation aspect of traditional drafting software. You can create models easily, but you can't document them: annotating, dimensioning (well), tagging, etc. A preliminary step would be to focus on what each program does well: SU is great at 3D object creation, AutoCAD or other 2d drafting programs are great at noting up 2d representations. Bridge these two functions with script that automates the export of 2D model representations using view planes: define a series view planes, each with a direction they are "looking", and the tool would automate the export of each view plane's 2D representation to a file or series of files. The resulting file(s) would then be linked into the drafting program for dimensioning and annotation. Updated views could be dumped out of SU periodically as design progresses.

Also, this strategy would allow you to manage file sizes in a way that does not over-tax either program. A wall section view plane in SU would be a cut through anomalous masses with certain thicknesses. When the 2D representation gets to the drafting program, details like insulation, studs, and anchor bolts could be added over the top of the section profile. This is essentially how Revit works in my experience anyway. Rather than drawing every stud in 3D, you draw them over the top of the section cut.

Eventually, it would be great to link this tool to tabs within SU and do the dimensioning and annotating in SU or Layout, but at least in the meantime this would give people a way to use their beloved SU models rather than having to ditch them when it comes to Construction Documents.

To pick up on one of Chris's earlier posts, I too think the old "Word Processor" template needs to be chucked. Revit and the other big guys have taken BIM in the wrong direction in creating a Family and Category based system of components that assumes every object needs to know what it is and should be governed by the rules of the category to which they belong. Why can't a wall be Sphere-shaped or a window be paraboloid? Why should the categories of model objects be fixed to some AutoDesk programmer's interpretation of what categories go into a building? If categories must be used, let people model whatever they want and ASSIGN objects to categories and CREATE their own categories instead. The same goes for embedded data and schedules. Try to get Revit to schedule Doors and Curtain Wall Doors and its a hack job - don't forget to exclude all the non-door curtain wall panels!!! Dynamic Components in SU allow users to control what kind of data is embedded in an object completely and does not limit the kind of data extraction routines that can be drawn up.

In my opinion, BIM as we currently see it is headed for the same train wreck of proprietary hacks and endless reverse incompatible new releases and patches. With the current level of modeling inflexibility, users will continue to complain that they can't make the program do X and software companies will continue to hack the programs to allow them to do so. Hack piled upon Hack and you get Architectural Desktop all over again.

Anyway, this is probably the wrong place to discuss the intricacies of how this could proceed. What about a SU-BIM Google group? I will make my marginal programming knowledge available for what its worth.