[Info] Allowable Classes for "set_attribute"

thomthom

Array -- good to store by doing "array.inspect" first, see Dan's comments below

Only if the array contains hashes. If the array only use the other allowable types there is no need. Might be less overhead since it's not parsing between strings.

thomthom

Geom::Point3d also seems to be possible to store:

` pt1=Geom::Point3d.new(1,2,3)
Point3d(1, 2, 3)
pt2=Geom::Point3d.new(4,5,6)
Point3d(4, 5, 6)
pt3=Geom::Point3d.new(7,8,9)
Point3d(7, 8, 9)

pt_array = [ pt1, pt2, pt3 ]
[Point3d(1, 2, 3), Point3d(4, 5, 6), Point3d(7, 8, 9)]

model.set_attribute('test', 'bar', pt_array )
[Point3d(1, 2, 3), Point3d(4, 5, 6), Point3d(7, 8, 9)]

model.get_attribute('test', 'bar' )
[Point3d(1, 2, 3), Point3d(4, 5, 6), Point3d(7, 8, 9)]`

I even saved the model and reopened it just to make sure it worked across sessions.

TIG

Although storing/reading-back a 'point3d' or a 'vector3d' as an array [.to_a] would be 'safer' ?
Presumably a 'transformation' is not storeable unless it's first made into an array ?

thomthom

@tig said:

Although storing/reading-back a 'point3d' or a 'vector3d' as an array [.to_a] would be 'safer' ?

I was storing points as arrays - because I just assumed point3d's would not work. But they appear to do so. In which case I'd prefer to do so unless there is any known issues.

kwalkerman

Nice. I just tested it as well. I'll add it to the list.

It also seems to work as an attribute dictionary key:

p1 = Geom::Point3d.new(1,2,3)
p2 = Geom::Point3d.new(4,5,6)

entity.set_attribute "k", p1, p2

--
Karen

thomthom

@kwalkerman said:

It also seems to work as an attribute dictionary key:

hmm... interesting.

I a haven't tried, but I'd think that Vector3d should work as well. (Though one can never be sure until it's tested...)

kwalkerman

yep, vectors work too. I wonder about the other Geom classes (although transformation doesn't work, I just tried it).

--
Karen

Dan Rathbun

reminder.. that keys should be unique, in the same way that hash keys need to be unique.

If you have two Point3d objects that are eql? (in the Ruby sense,) ie, the 3 elements, x, y, z have the same values, (but differing object_id,) can they be used as separate keys for 2 separate values ?

.. or will one overwrite the other's value in the dictionary ?

kwalkerman

Dan,

Good point. A quick check indicates that any point with the same x,y, and z values can access the attribute.

--
Karen

Dan Rathbun

@kwalkerman said:

Good point. A quick check indicates that any point with the same x,y, and z values can access the attribute.

Karen

.. thot so.

This could be bad,.. or good, depending on what your doing. If you wanted to store some explanitory text for ANY point with certain x,y,z co-ordinates like "at the hinge point" then this feature might work ok. (Of course, nil will be returned if no such "point-key" exists in the dictionary.)

kwalkerman

Dan,

For applications I can think of, this is actually an advantage, especially if you are using attributes between sessions, as the 'entity' attached to your particular point3d would be lost. AND, it works just like any other key for attributes.

string1 = "My Attribute"
string2 = "My Attribute"

entity.set_attribute "a", string1, "q"
entity.get_attribute "a", string2 ==> "q"

string1 and string2 are different objects, but both can reference the same attribute dictionary.

--
Karen

jiminy-billy-bob

Shameless bump, it would be great to add this to the online docs. (TT, if you read this...)

eneroth3

Perhaps it's worth mentioning that Point3ds and vector3ds are transformed along with the geometry they belong to when using move tool or rotate tool on it.

Dan Rathbun

Geom::Point3d and Geom::Vector3d are virtual classes. Instances of them do not actually exist in any entities collection. Sketchup::Vertex however, does have instances "in the model."

Can you be more specific? (Your statement seems vague.)

tt_su

Christina is correct, any Point3d and Vector3d stored in an Entity's attribute will be transformed along with the entity itself.

I don't have a list of what classes can be stored, I'll look into it.

eneroth3

After some tests in SU2013 I found out that these classes are not transformed when using move!, transform! or transformation= on the entity, but they are when using the move, rotate or scale tool on it.

This might be quite useful for custom animations scripts since things like rotation axes etc can be saved as attributes to the entities being transformed without be changed by the animation. When creating the mechanic parts for my railroad plugin I turned these data into normal arrays to avoid them from being transformed but perhaps that wasn't required.

tt_su

Poking into the source here.

set_attribute converts Ruby values into C++ types. The functions that handles it deals with the following types:

True/False
Length
Integer
Float
String
Array (Containing any of the other types)
Color
Time
Point3d
Vector3d

And if its not any of those types it appear to silently ignore it. An empty setting is written. (It'll write the key, but value will be empty.)

jiminy-billy-bob

Thanks for the list!

Jim

Does "allowable" also mean these types are converted back into their original object types by get_attribute?

(I know it does, but didn't see that explicitly mentioned in the topic.)

tt_su

Yes, they should. But there might be some quirks in the underlying implementation of storage, where Windows stores to the registry and OSX saves to a plist. I think I recall some escape character issues on one of the platforms - though I don't recall the details. Might have been fixed.

[Info] Allowable Classes for &quot;set_attribute&quot;

[Info] Allowable Classes for "set_attribute"