Nz_attribute

Extensions
, ,
1

nz_attribute is one of the new releases by developer Natale Zappia (I don’t know if he’s active on the forum, so I couldn’t ping him). Natale, if you’re around and see this, kindly respond to the below.

I’d like to know a few things, for those who may have tried this extension:

  • can we customize the amount of attribute fields?
  • can custom name these attribute fields?
  • what are the maximum number of characters for entry per field?
  • do all these attributes, per their custom fields, show up in the Entity Info, if this is the case then auto tagging / auto labeling features in both SketchUp and Layout can be used to reflect all of attributes entered.

Feature Request should this extension be able to reflect all attribute field (custom or otherwise) in Entity Info for auto labeling / auto tagging in both SU & LO: (I don’t think it is part of this extension already)

  • ability to link external files
  • ability to reflect text in externally linked file (say a TXT document) and have this show up in the designated attribute field (-s)
  • ability to hotlink (as in click on to open) website URL’s in a particular attribute field
  • ability to set LOD for annotation purposes (as in BIM methodology) without necessarily having to change the text / input set per LOD (obviously one would have to enter such information at some stage before, I’m thinking entering all relevant info and choosing LOD level for info display in auto tagging / auto labeling).

Should one be able to do all of the above, this extension would have some serious capabilities.

I know of one other extension (privately developed by a very capable developer, but not released to the general public) that comes close to this, but the information / attributes are not able to be injected to the Entity Info field, thus auto tagging / auto labeling in both SU & LO cannot utelize the information.

1 Like
2

NO, the “Advanced Attribute” list in Entity Info is hardcoded and only configurable (currently) by the SketchUp Developement Team. This means extension developers have no control over these “Advanced Attribute” lists in Entity Info.

There are already a number of free Attribute Editors that you might look at. One by the SketchUp Team, one by Aerilius (uses a single window) and one by Eneroth (which opens each dictionary in it’s own window.)

Linking in external files complicates things. What happens if the SKP file is distributed without the “companion” files ?

But I believe there are some extension that link in Excel or CSV data files. (LayOut does this as well I believe.)

Importing data to dictionaries is doable. Export as well.

Doable if from a HTML dialog. Care must be taken as this could become a malware attack vector.

(The Entity Info field is an edit field so clicking on it activates it for editing.)

3

Thanks for the insight Dan. So, to be clear, there are currently no extensions that can modify the ENTITY INFO information? Would there be any other methods (or extensions you may know of) that is able to pass custom info to the SU / LO auto labeling / auto tagging features?

4

Correct. Well… I mean none that can force the listing of new advanced attributes. Extensions can add actual attributes or change existing attributes of those special "SU_" dictionaries. (But cannot delete these dictionaries.)

EDIT: Maybe try using Aerilius’ Attribute Inspector to add some custom attribute to one of the "SU_" dictionaries and see if you can use it from LayOut. It just will not be editable from Entity Info.

Perhaps dynamic dictionaries (named “dynamic_attributes”.) I can’t remember exactly. I wasn’t very impressed with the function when it first was implemented (several cycles ago.) I remember asking for a “DictionaryName:CustomAttributeName” syntax be implemented, but I don’t think it yet has been.

5

It’s not entirely correct about to possibility for reading/writing the special ‘SU_’ attributes
as shown in Entity Info…
You can’t delete the attribute_dictionary as SketchUp will recreate an empty one any way !

BUT if you have a reference to the instance 'i' 
i.get_attribute('SU_InstanceSet', 'Owner', '?')

i.set_attribute('SU_InstanceSet', 'Owner', 'AcmeWidgets')

The available ‘keys’ are ‘Owner’ and ‘Status’

AND if you have a reference to the instance.definition use 'd': 
d.get_attribute('SU_DefinitionSet', 'Price', '0.00')

d.set_attribute('SU_DefinitionSet', 'Price', '1.23')

The available ‘keys’ are ‘Price’, ‘Size’ and ‘Url’

6

What’s not entirely correct ?

7

I meant that your post gave the initial impression that these SU_ attributes were not accessible…
The dictionaries are auto-generated, but their ‘pairs’ can be read/written in RB…

8

Oh well I made 2 posts. The first I explicitly was trying to speak to controlling the display of advanced attributes only.
In the second post, you might have missed the edit, or began replying before I could get the edit complete. I began editing almost immediately after initially just replying “Correct” to Julian’s “to be clear … modify” question as I realized that I was answering again the initial question of display control, and not the newer question of modification.
So I edited twice adding two statements following “Correct.” One immediately, that specifically says that extensions can add and change attributes to these “advanced” dictionaries.
The the second (begins "EDIT,) a few minutes later. I thought for a few moments and decided I wasn’t sure if Julian was into coding, and because this isn’t a API category, I thought I’d not post nitty gritty coding specifics but advise a manual testing approach using one of the attribute editor extensions.

Now all that said, … we should discuss a disclaimer. These two "SU_" prefixed dictionaries were invented to support some internal native functionality that isn’t entirely completely implemented (according to team member statements,) or can change and be added to in the future.
(Ie some vague reference to "plans … down the road, etc. … likely IMO having to do with reports and / or costing features.)

So even though adding to these might work (to pass data into LayOut) in the short term, it runs the risk of clashing with the planned functionality of these dictionaries in the long term.

And … I just tested.

1a. Adding a custom “SU_InstanceSet” attribute will bring it into LayOut as a Label but does not show the attribute name, just the value in the Label list.

1b. Adding a custom “SU_DefinitionSet” attribute will bring it into LayOut as a Label but does not show the attribute name, just the value in the Label list.

This can cause confusion as to which (definition or instance) that the “Advanced Attribute” data comes from.

2. Adding a custom text attribute to a DC component’s dictionary will bring it into LayOut as a dynamic label (has the green DC icon to the left of the attribute name.) This method does show the attribute name.

IMO, it seems that (2) is the safer workflow pattern as it also does not require special extensions. Just use the Dynamic Components dialogs to add and edit your new data attributes to components.

1 Like