I don't have any code right now, I will once I have access to it though, which should be in a couple of days. The general procedure works like this though. Before anything else, I store the initial orientation by making an axes type Transformation. Something like this if memory serves well : xaxis_ = cInst.transformation.xaxis yaxis_ = cInst.transformation.yaxis zaxis_ = cInst.transformation.zaxis @transform = Geom;;Transformation.axes(Geom;;Point3d.new(0,0,0),Geom;;Vector3d.new(xaxis_.x,xaxis_.y,xaxis_.z),Geom;;Vector3d.new(yaxis_.x,yaxis_.y,yaxis_.z),Geom;;Vector3d.new(zaxis_.x,zaxis_.y,zaxis_.z)) The translations to move to and from the origin are created using the center of the bounds of the component. The origin to object axes are also calculated with an axes type Transformation. I use the inverse to return from global to local. The rotation part of the external transformation is created from an array, with indices 3, 7, 11, 12, 13, 14 set to 0 and index 15 set to 1. Said array comes from extracting numbers from a string. I thought there might be some bug or some accuracy loss here, but it's a double to float conversion on mostly small numbers, and checking the orthogonality of the rotation component gives no error before the 12th digit. The translation part (which is global, not relative to the component, btw) is used to make a vector used to make a Transformation. I've had the skewing even when this was 0, though. And then it goes like this : -Store initial transformation. When transformation is received : -move to origin -switch from object to origin axes -Compensate the initial transformation if there is one. -Apply rotation -apply the inverse of the initial transformation -go to object axes -Apply translation (global) -Move back from the origin Granted, it's not the best workflow. However, given the accuracy I seem to have on the sole matrix that isn't created within SU, I don't understand how the skewing happens, particularly when multiplying all these external matrices together yields an error that is so tiny.

@oajfh said: ...Tool Observer (OnButtonUp and OnButtonDown) ... There is not a ToolObserver class in the API. The onButton.. callbacks are part of the abstract Tool class, not an observer class. @oajfh said: ... and an EntityObserver (OnEntityChange), ... Write a quick test observer and see if it fires when you move an object. @oajfh said: Does this seem like the most natural way to you ? Are there any latent bugs (seems like Observers have had problems in past versions, I can't seem to find more recent information) or potential problems to this approach (I've read up on a few common pitfalls but don't know much more) ? Welcome the foggy world of SketchUp API Dcoumentation. Where nothing is really certain, and all are kept in limbo.

@oajfh said: Sorry for dragging this topic on for so long. Don't worry about it. This is the kind of nitty-gritty dirty details us consummate geeks really love to ponder.

@oajfh said: Perhaps there's an implicit point to vector conversion or vice-versa, but in that case the API makes no mention of it. In mathematics, both are represented as arrays. @unknownuser said: ** class](http://www.sketchup.com/intl/en/developer/docs/ourdoc/array.php)":1hykbm7x] Introduction The SketchUp Array class adds additional methods to the standard Ruby Array class. Specifically, it contains methods allowing an array to behave just as a Vector3d or Point3d object (which can be thought of as arrays of 3 coordinate values.) Therefore, you can use the Array class in place of a Point3d or Vector3d as a way to pass coordinate values. The opposite is also often true, as well. The API docs need updating in regard to allowable parameter types. P.S. - The docs are misleading when it says "The SketchUp Array class ..." There is only one Array class. The SketchUp API just modifies the Ruby Array base class.

EntityID are unique for the model - but entities will be assigned a new ID each time you open it. They are not persistent. There will not be two entities with the same entityID in a model. ComponentDefinition GUIDs change as you modify the definition. ComponentInstance GUIDs persist - even if you edit the instance/definition.

IN Ruby 1.8 for loops used to be faster - at least in the tests I performed on my extensions. But Ruby 2.0 swapped that around. In any case - you don't really know until you profile your specific case.