Storing attributes?

tomot

The particular thoughts expressed here:
http://forums.sketchucation.com/viewtopic.php?f=12&t=15911&start=255
Reminds me of having spend way, way to many years with AutoCad, well over 10 years ago, where I developed a Lisp Attribute List, that each cad user had to fill out prior to inserting a Door into a drawing. Hence from this Attribute list we were able to extract a door schedule, which was able to be printed out on a predefined 8.5" x 11" sheet for inclusion in the Specification Manual. And since each door had its own Attribute list we could Edit the Attributes for each door, should changes occur. I'm wondering if this Attribute concept could become a viable Ruby? and is it possible to store user defined attributes within an inserted component via Ruby?

curious!

HPW

Hello,

Sound like you want to use dynamic components.
Have you had a look at them?
They can get attributes and there are plugins to extract them (I think)

Hans-Peter

TIG

Many scripts already store specialist custom attributes and recover/modify them...
You can add custom attributes to most 'objects' - e.g. the model itself, materials, component-definitions, component-instances, groups, individual entities like text, and faces and edges [although these can be 'volatile' and can therefore easily 'disappear' from the model].
To 'set' an attribute use:
object.set_attribute("MyDictionary", "mykey", value)
The 'value' can be one of several types of data - a boolean [true/false], an integer [1, -1, 0, 1234], a float [1.234, -325.6], a string ["cat", "hat"] or as an array of any of these - e.g. [1, 2.3, "cat"].
To 'get' an attribute use:
object.get_attribute("MyDictionary", "mykey", default)
The default is an optional default-value to be returned if the object doesn't have that 'key' [otherwise it returns 'nil'].
You can add any number of custom attribute dictionaries to an 'object', and then pairs of keys and values to those.
There are several methods to erase dictionaries en mass, get all of their keys/values etc etc.
Attributes are remembered with the saved SKP.
You can script ways of reading attributes into CSV/TSV files as reports etc.

A Dynamic Component is just a component made with with complex arrangements of special 'dynamic_attributes' that interact in specified ways. You can extract attributes from these OR from any other entity that has attributes set...

tomot

Here is a short list of what such a Door attribute list might contain:

Room No:
Door No:
Door Orientation: LH, RH, LHR, RHR
Number of Butts: 4, 3, 2
Butt Type: ss steel, ball bearing, exterior, interior
Return air panels: y/n
Glazing panels: y/n, wired
Weather stripping: y/n
Non-combustible sill: y/n
Kick Plates: both sides, y/n
Locking: Latch set/Lock set
Material finish: steel clad, solid wood, hollow core, solid core, lead shielding
Door Sweeper: y/n
Door Closer: y/n
Door Fire rating:
Door Frame rating:
Astragal: y/n
Head profile detail
Jamb profile detail
Sill profile detail

none of this stuff needs to be shown graphically, but it needs to be printed on a form, so it can be priced.

Dan Rathbun

It is very important to choose a unique name for your plugin's attribute dictionaries !

Let us say (for example sake,) that your toplevel namespace that you use is Tomot.

Let us imagine that you create a scheduler plugin, in a submodule, called Tomot::Scheduler

It would be good practice, to prefix the names any AttributeDictionary object, that your plugin uses (no matter what kind of object it's attached to, with the prefix string: "Tomot_Scheduler_"

So if you attach a dictionary to a door component, it might be named: "Tomot_Scheduler_Door"

So if you attach a dictionary to a window component, it might be named: "Tomot_Scheduler_Window"

You name similar things, in a similar way, such as: piping, electrical, framing, ... etc.

Now if you wish to have a master dictionary index, attached to the model, you might name it: Tomot_Scheduler_MasterIndex"
... which indexes, the subindexes, like: "Tomot_Scheduler_Door_index", "Tomot_Scheduler_Window_Index", etc.

I think you should get the idea.

tomot

Looking at the response so far to my original question, It appears this might be possible. Unfortunately I don't see the typical Ruby Windows Dialog as the most inviting way to fill out such a form. I'm wondering if a secondary script dealing only with selecting 2d existing doors on a drawing would be a better way of initiating such a script that would add this information for each door?

TIG

The dynamic-component's attribute dialogs allow input and reporting of attributes.
You can set pick-lists, numbers etc as the input for different properties of each door.
Bear in mind that the DC doesn't need to be 'a door', it could be a 'tag' that you associate with a door element - it would only display the door-reference, but hold all of the other [editable] data too ?

Dan Rathbun

2D or 3D makes no difference.

Yes the UI.inputbox() is rudimentray (and has formatting issues,) ... but it can be a first step in developing the plugin.

Later, you can design a nicer UI::Webdialog object (similar to that which Google uses for the Dynamic Components extension.)

Regardless of using UI.inputbox() or UI::Webdialog, you will still need to define (WITHIN your plugin namespace,) arrays of your dictionary keynames, and options (which can be tied to a particular key, by prefix naming):

keys:
Keys_Door = ['Room No','Door No'.'Door Orientation', ...etc... ]

options:
Options_Door_Orientation = ['LH', 'RH', 'LHR', 'RHR']

These arrays will be used to load into and control the UI, whether it be UI.inputbox() or UI::Webdialog

You might consider loading these from files (similar to the LanguageHandler strings format,) so as to make the plugin extensible, WITHOUT reprogramming.

Dan Rathbun

@tomot said:

Looking at the response so far to my original question, It appears this might be possible.

Of course it's possible.

FYI: Dana Woodman made a similar plugin that produced cabinetry schedules, called CutLister.

http://www.extendsketchup.com/plugins/cutlister/

tomot

thanks Dan and Tig I will have a look at that!