Ok thank you Dan. I will try that.

thank you very much Thomas and Tig that prompt reply! I will try to implement your suggestions right now

By 'hand built' I mean 'made manually', i.e. without using any code... that's all... If you make a group that straddles the origin, then its origin [axes] are located at its bounds.min... As I tried to explain... you can then move that group from its insertion_point back to the model ORIGIN, and then apply the same translation transformation BUT as an 'inverse', to the group's entities... so that it appears in the same place in the model, BUT its actual axes have been relocated to the ORIGIN...

Not that i know of....

Thanks Dan, Your suggestion to write callback that is called from killing object, was very useful idea - and makes nice readable code. Much better idea then various signals I planned to use before. Thanks again, Marija

@dan rathbun said: obj.respond_to?(:activate) Thanks Dan, description - sure will help. Edited: Previously, I used obj.methods.include?(someMethod). - That will give an error if the object wouldn't be a class, nor module. But using respond_to? will work on any selected object without errors. Jst true or false I was wrong in blue words. Actually, .methods can be implemented in any object. 134.methods, nil.methods, "dsfg".methods, false.methods, Class.methods will always work.

So assuming you want some data encapsulated within the script file itself, that will use it. A Here Doc, or Array or Hash, would seem to be a much easier solution.

Thanks a bunch TIG, I forgot you could get the arcs edges! Still organizing all this information

@tig said: You are only ever giving us half the story... Sorry about that! I clearly had some difficulty thinking outside the box. The empty definition did not work in this case, so I added a dummy line definition entity and erased it. #----Do dummy line entities = def_stair.entities # def line = entities.add_line (@p8, @p7) entities.erase_entities line all is well now, thanks! [image: ApAv_stair1.png]

@thomthom said: Don't know about 1.8.7 - but they tried 1.9 I think. So did I !! The main issue is that that they (the Ruby Core guys,) renamed functions on the c-side, without leaving aliases that would properly call the newer named functions. This is the character encoding realm.

@jim said: Either way, can't you just get the active model from the selected entity.. Or from the Selection itself? Keeping in mind that on Mac there can be multiple model objects open.. each with it's OWN selection object, which it's it's OWN selected entity.

@dan rathbun said: You neglect to show the require() staement that loads Dan Berger's win32-api extensions. (This example does not use the Win32API.so file, that comes "out-of-the-box" with Ruby.) Thanks for pointing that out. Yep, the code above requires win32-api

@rvs1977 said: I wonder why the eval-rescue solution has to be avoided? Is it slow? ALL String operations in Ruby 1.8.x are slow. eval() is the Ruby code parser.. so it is a very large method (actually a C-side function.) But I cannot see it being slower than the 2 iterator methods you are using, in addition to the type converter. But it works... and you understand how it works. If speed is not an issue, then go with it ... Also if you KNEW each numeric was separated by a "," then you also do: @YV_array = yv_array.split(',').map{|i| i.to_i}

Perfect, those rendering options will come in handy! This works great, thanks Jim

@anton_s said: I recommend putting the whole __FILE__ That's very reasonable. I'll fix it. I just wanted to let you all know that I'm working on improvements (esp. the snippets should have been saved over sessions) but I'm a bit busy at the moment. I'll publish a next version when I'm ready.

Joe, Thanks for posting this. I was going to eventually, but got tangled up in other things and didn't get around to it/ I hope it is useful to others. Steve

Thanks ! it's works and I use def scaleX() Math.sqrt(self.to_a[0]**2+self.to_a[1]**2+self.to_a[2]**2) end def scaleY() Math.sqrt(self.to_a[4]**2+self.to_a[5]**2+self.to_a[6]**2) end def scaleZ() Math.sqrt(self.to_a[8]**2+self.to_a[9]**2+self.to_a[10]**2) end

Hi Thom, Here is example and results (I'm obviously doing something wrong, but not sure where the problem is). In model I have 2 groups: group1 - consisting of 2 subgroups, where one subgroup contains face we analyze in example group2 - consisting of some object. Here is the code, to get the face I go through hierarchy - but every time it is the same face face = Sketchup.active_model.entities[1].entities[1].entities[14] p1 = face.outer_loop.vertices[0].position t1 =Sketchup.active_model.edit_transform p1_trans_inv = p1.transform(t1.inverse()) puts "P1 coordinates [#{p1.to_a.join(',')}]" puts "Edit_transform [#{t1.to_a.join(',')}]" puts "Edit_transform_inverse [#{t1.inverse.to_a.join(',')}]" puts "P1_transform_inverse [#{p1_trans_inv.to_a.join(',')}]" Absolute P1 coordinates in SU coordinate system are:[-393.700787401575,196.850393700787,0.0] I call this small script for various cases of opened groups inside model and here are results: *opened group where face is P1 coordinates [-393.700787401575,196.850393700787,0.0] Edit_transform [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,-548.031496062992,196.850393700787,0.0,1.0] Edit_transform_inverse [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,548.031496062992,-196.850393700787,-0.0,1.0] P1_transform_inverse [154.330708661417,0.0,0.0] *closed group with face, opened parent group P1 coordinates [154.330708661417,0.0,0.0] Edit_transform [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,-548.031496062992,196.850393700787,0.0,1.0] Edit_transform_inverse [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,548.031496062992,-196.850393700787,-0.0,1.0] P1_transform_inverse [702.362204724409,-196.850393700787,0.0] *closed group with face, opened parent group, opened other group in the parent P1 coordinates [154.330708661417,0.0,0.0] Edit_transform [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,-367.646959030915,310.128373863173,80.3149606299213,1.0] Edit_transform_inverse [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,367.646959030915,-310.128373863173,-80.3149606299213,1.0] P1_transform_inverse [521.977667692332,-310.128373863173,-80.3149606299213] *closed group, closed parent group, opened some other group P1 coordinates [154.330708661417,0.0,0.0] Edit_transform [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,-464.698354923942,49.8468801242114,-1.13686837721616e-013,1.0] Edit_transform_inverse [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,464.698354923942,-49.8468801242114,1.13686837721616e-013,1.0] P1_transform_inverse [619.029063585359,-49.8468801242114,1.13686837721616e-013] *closed all groups P1 coordinates [154.330708661417,0.0,0.0] Edit_transform [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0] Edit_transform_inverse [1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,1.0] P1_transform_inverse [154.330708661417,0.0,0.0] As you can see using inverse edit_transform gives each time different results for 'P1_transform_inverse', depending which group is opened - and my goal is to get in each case the same results (since these should be absolute coordinates) Also notice- that when group with face is opened- we get absolute coordinates (and not relative to the group origin), while in all other cases we get relative coordinates for p1. So as in previous mail my question is how to get correct absolute coordinates for all other cases (when group with face is closed, and some or no other groups are opened)? Thanks for patience, Marija

No there is no documentation. Technically... DynamicComponents is a Google/Trimble extension. And it is not OpenSource. Practically... it works (and is thought of,) as part of the Sketchup application itself. (The fact that it's written in Ruby, raises some stability issues if a lot of people began messing with it. And.. also, it would run alot faster if it was re-written in C/C++.) What you may not have realized.. is that DC are really just Sketchup::ComponentInstance instances, that have specially named attribute dictionaries and attributes, that are used by the extension, to do nifty things. Because it is an authored extension, it's internal workings are subject to change. Even it's internal methods could change their names, but externally, end-users, and scripters, might interact with them in the same way (or without much change.) So, much of what we know, has come from little tidbits, revealed by the members of the SU Dev team, .. and we can assume, that they have told "the world", what they are comfortable revealing. Or.. it may be that Google was never willing to spend the money, to produce the documentation. Or perhaps.. maybe the Ruby version V1 is the proof of concept... and they always had hopes of "baking it into" the C-side API code. (But just have never had that phase percolate to the top of the "to do" list.) Anyway.. if that happens, who knows what the method names exposed to Ruby might be ?? This latter possibility, is the reason I never attempted (even though I thought about it,) to write a reference manual for DCs myself. (That and I would imagine, they would have to give their "blessing" for it. I'd never do something like that without asking. Wouldn't like it if someone did it to my closed source work, without permission.)

Using the "K" button will help you view hidden lines quickly. This can help GREATLY with connecting faces. Also it helps you snap components that get confused with the zoom.