@thomthom said: What are the problems you're having with the attributes? Example? Well, I opened up the Sketchup Attribute Manager. http://code.google.com/p/sketchupattributemanager/wiki/Welcome. Using this, I made a simple dynamic component. When I loaded the attributes X, Y, Z onto the component, they showed up on the attribute manager. Then when I moved the block, reloaded the attribute manager, the new coordinates were not updated. This same issue happened when I scales and rotated the component, compelling me to believe the problem was most likely with the attribute manager not reading the dc (even after I hit redraw). I don't know of something similar to the attribute manager that will work with DC's, and that' my real difficulty. Without it, debugging this idea will be difficult without knowing exactly the formatting of the current functions.

@hpw said: And when do that countries get 7.1 ? within eigth months? Regards

If you can do VBA macro programming, you've got the foundation for Ruby. Warning: Ruby is a big language. Solution: Google up Chris Pine's Ruby tutorial. New topic. Don't Edit/Hide (or Shift+Erase). One of the things I missed coming from DWPro to SU was the former's two-state hidden model. Hiding something moved it into a second model. A shortcut let you toggle back and forth between the "hidden" and "not hidden" models. It was nice. Then I realized that SU had this capability, only better. Don't use Edit/Hide. Create a "hidden" layer and slide geometry into that layer. Or use multiple "hidden" layers. The gremlins that do untimely unhides don't mess with your layers.

But actually, merci bien a vous, Bert! That's what I was looking for. Cool.

@richmorin said: Experimentation indicates that function arguments are passed to the Ruby method as an array of strings. Well, obviously the entire formula begins as one big lengthy string, is repeatedly parsed and broken up into smaller and smaller tokens, until it can build it's param arrays to pass to internal DC functions. However it's not always necessary internally (DC parsing) for the params to be passed as string representations, to the DC formula method(s), if it was already necessary for the DC parser to convert the sub-string operands to a Numeric (for say, some logical comparison, in order to make a code branching decision.) @richmorin said: So, it seems like the Ruby method should be performing coercion on the input values. (eg, a[0].to_f). Exactly what they all of the mathematical DC functions do internally, just to be safe, before passing any values to methods in the Math module (or otherwise where a Numeric type is expected.) IF you just have to modify the DCFunctionsV1 class, for your own use, it would only be smart, to also do .to_f() coercion. @richmorin said: Am I missing something? Only that there are some DC functions that specifically use string args. (But we can ignore this for this issue...)

Class of '07 man! Spent most of my time in Building 17, learning about forces this, energy that... I should go back for my masters but I needed a job...

Hi Markozeta, My previous post wasn't a request just a query, but thanks for taking the time to actually sort it out. It works brilliantly, well done. Now to make a square peg to fit in the round hole

Hi, Thanks for the explanation/tutorial on how you achieved this DC. Makes for very interesting reading and deserves a bit more attention than it is currently getting. I hope more users check this post out to see how much work goes into such a simple concept.

Moved to layout wish list, seems more appropriate Good suggestions btw, keep 'em coming. Im sure the chaps over at google will be interested to hear your suggestions.