Only Sketchup::ComponentDefinition and Sketchup::ComponentInstance will have dictionaries with that special name.

@adamb said: Rich, why is your avatar Brian Blessed? Gordon....He's alive!!! It's not Brian Blessed unfortunately. It's Action Bronson... [image: action-bronson-terry-richardson-8.jpg]

I can do it now ! def glass_groups model = Sketchup.active_model model.start_operation( "Face Offset" , true) selection = model.selection entities = model.active_entities #entities = model.entities arr = [] faces = [] selection.each{|entity| if entity.class == Sketchup;;Face arr.push entity end } $face_offset = 13 $glass_thickness = 6 prompts = ["Offset Width [mm] ", "Glass Thickness [mm] "] defaults = [$face_offset.to_s,$glass_thickness.to_s ] list = ["",""] input = UI.inputbox prompts, defaults, list, "Offset Face." doffset = input[0].to_f $face_offset = doffset berase = true # 1. Offset Glass + Erase outer faces arr_glass = [] arr.each{|entity| face = face_offset1(entity, doffset.mm, berase) arr_glass.push face } entities.each do |e| faces.push e if e.is_a? Sketchup;;Face end # 2. Glass Thickness + Group's Name distance = input[1].to_f n='Glass unit' faces.each do |e| # e.pushpull distance.mm, true g = entities.add_group e e.pushpull(-distance.mm) g.name=n ############### end model.commit_operation end

@inteloide said: Now, the problem is that @@var must be define in B.rb : what about if I need to create a third file which require @@var ? I must declare again the same variable ! NO.. the @@var is a module variable. It is SHARED by ALL classes and modules that include the mixin module M::I If you change @@var value from an instance of class M::A, all other instances will see the change. Also any modules that included the M::I mixin will share the @@var. (It is a proxy lookup INTO the mixin library module M::I.) Files are NOT included (that is a Python feature.) IN Ruby modules are included. A file can define multiple modules. @inteloide said: Any solution ? (Because in my plugins, there are a lot of variables used in a lot of sub-programs... If you want each class instance or sub-module to use it's OWN variables, the use instance vars, ... @var (only a single @ before the variable name.) This is all basic Ruby, explained in the "Pick-Axe" Book.

It is in my code. I just simplified everything to paste this snippet.

hi dan, super, thanx, i understood and it works now, besides a small message in the console: load '01.rb' C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/01.rb:66: warning: already initialized constant THISFILE true i start the ruby directly, not in a module (when i put it in the module, it does not work, probably because of all the entities definitions etc. / still workin' on it) regards stan

An object like a group has a bounding-box with its XYZ axes a parallel to the groups' internal XYZ axes. So if the geometry inside the group is made parallel to its internal axes then its bounds hug the geometry. If you rotate the group its bounds rotate with it. If you rotate the geometry inside the group then it is rotated relative to the group's internal axes. So although the visible geometry is rotated the bounds stay as they were - now skewed... tr=Geom::Transformation(point, axis, angle) group.transform!(tr) Rotates the group [AND its geometry inside] so the bounds rotate. tr=Geom::Transformation(point, axis, angle) group.entities.transform_entities(tr, group.entities.to_a) Rotates the group geometry inside BUT leaves the group where it was, so the bounds do not rotate - so it is skewed... If you have skewed geometry that is made into a group the group.bounds are skewed relative to the geometry. To fix this first rotate the group then rotate the geometry in the opposite direction [use tr.inverse]. Visually it's unchanged but the bounds now match the geometry and the group is actually rotated... tr=Geom::Transformation(point, axis, angle) group.transform!(tr) group.entities.transform_entities(tr.inverse, group.entities.to_a)

@unknownuser said: I have started a plugin with several inputbox following each other and i realised the width of the input box varies mainly with the first line but not really... Easy fix; I think you can move the right inputbox drop down margin by a tab and (n) spaces on the right of largest number in list example 1) 1 tab 6 space lists = ["3.0|0.333333333333333333333330 tab sp sp sp sp sp sp|44.0"] box will now show 0.333333333333333333333330 to the zero place

Apologies for the delayed response. Here is how a user would use the Plytool (the tool that creates a box/ply) Click on the tool icon. Now click (to mark the first point) and start drawing the ply [image: YZwl_1.png] Stop at another point (which is the second point). Leg go the left click and you have your ply [image: DK4W_2.png] Coming to the questions @tig said: From what you've said you don't actually want to stop the user having the PlushPull tool available to them ? Correct. I don't want to stop the user from using Push/pull but just restrict the user from pushing or pulling on certain kind of faces [e.g - vertical faces only]. @tig said: Limiting the user's choice within your tool of available faces for this pushpulling is a matter of testing a face for its suitability - this can be whatever you want - orientation of face.normal [e.g. only 'up' faces], or faces using a particular material or layer ? That way your own pushpull tool will simply work in limited ways... Yes, this seems like the suitable option to try. I will try this and get back if any questions. Ideally I would have preferred the ability to override pushpull tool (thereby not introducing a new limited version of pushpull tool). But this should do for now. Thanks guys for helping me out and clarifying what is possible and what not.

hi icehuli, that's it! of course, i already had the tanges, so......sometimes it's so clear afterwards... thanx a lot, the method works now! new_line = @entities2.add_line @pfm1, @pfm2 @vector = new_line.line[1] point = [0,0,0] angle = (Math.atan(var4/@run)).radians angle = 360 - (Math.atan(var4/@run)).radians if var5 == "right" tr = Geom;;Transformation.rotation(point,@vector,angle.degrees) @group.entities.transform_entities(tr, @group.entities.to_a) stan

@artmusicstudio said: MODULE 01.rb // is it right to put hier 01.rb ??? (the work-name of the ruby) No you cannot use a Numeric expression as a Class or Module name. They must begin with alpha characters, and be title case.

@dan rathbun said: The viewer writes it's settings into it's own registry hive on PC, so it is separate from the Make or Pro SketchUp settings. These viewer registry settings would be left behind on the workstation, but should not cause any problems. The more important isssue is if the workstation will have all the required libraries already installed on them. Such as the correct version of the C runtime library. Dot NET libraries, etc. thank you for these informations i don't understand everything, but from what i understand, it should be possible to use su viewer in a portable way

@mptak said: In general Ruby (or Python as well) it seems that you use subclasses but this seems problematic. Yes, though then it's normally in a server environment where you have more control over the environment where your code is run. In SketchUp the user controls the environment and the developer is the guest - flipping the roles.

Not allowed to PM yet, but email has been sent

I know exactly what you mean - I've built a lot of curved staircases. The challenge when it comes to modelling is to try an approximate the handrail profile and to manage ( or control ) the distortion. You feather the distortion over a distance so as to minimize it visually.

There is BoundingBox.intersect But I gather you want to be more precise than so. So it will cost to calculate intersections for many Groups however you do it. You don't mention if is this is on 1 plane or 3d.

@avariant said: Thanks! Look forward to that day (I hate COM). +1

I know what he meant.. my arg still stands. Sometimes "active" is appropriate.. other times "selected" is more appropriate. Still other times "current" may seem more appropriate. There is a difference between the terms. They are not direct synonyms.

You can collect all the separate loop-segments from the selection and then treat them separately. If you made the assumption that the user only selected one edge in each of the loops he/she wants selected then it's easier - as you just need to iterate each edge in selection and build a loop for each one. But it could be that the user selected multiple segments of a loop, in which you would have to detect this as well. Or, thinking of it, you could just ignore the fact that some are connected, just build the loop anyway and make sure you don't process an edge that's already in a generated loop.

blink -- me neither! I guess I always just skipped over that method...