Document Attributes vs. custom PropertySets (hidden iProperty sets)

[DRoam]

For programming purposes (iLogic, VBA, API, Add-ins, etc.), if we want to store information about a document within itself, we have two tools for doing so: Attributes and Properties.

Both of these are essentially "value containers". Both of them are tied to the document itself. And, if we assume we're using custom PropertySets and not the built-in ones, both of them are only accessible via the API; they are not visible anywhere in the user interface.

My question is, why would I choose one over the other for a given application (such as an add-in)? What are the different capabilities of attributes vs. properties? Aside from capabilities, are there any unique behavioral characteristics between them (e.g. how they respond to certain document events)?

From what I understand, AttributeSets have the following unique capabilities/characteristics:

• They can be created on objects other than the document object (an irrelevant point for this discussion)
• They can be created as "transient" (so they only last until the current Inventor session ends)
• In addition to the String, Double, Integer, and Boolean types that Properties can have, Attributes can also have a "Byte Array" type (whatever that means).

So, what is a "byte array"? Am I missing any other unique capabilities/characteristics? Is there any reason not to use Attributes, since they seem more versatile than Properties?

PS: This is potentially a very similar topic to this one: Add-ins: Best way to store AddIn-specific information in a document. But I thought it would be useful to create a dedicated discussion for it, because I haven't seen the distinction between these very similar tools discussed anywhere else.

[NachoShaw]

Its interesting to read that attributes can hold a byte array. I use byte arrays in another inventor application. Basically you should be able to store any other document as a byte array and retrieve it to view with a stream reader. For my purposes, I store pdfs as byte array in a remote database.

Reading that has opened a few possibilities for me 🙂

[DRoam]

@NachoShaw wow, that is indeed interesting. I would have never thought you could store a document in a variable like that. Not sure what I would use that for but definitely a powerful capability.

[DRoam]

Other than that... I wonder if one of the developers could shed some more light on this? @MjDeck, @chandra.shekar.g, @YuhanZhang, is there any reason not to use document Attributes, rather than custom PropertySet properties, to store document metadata for add-ins?

[MjDeck · Accepted solution]

Overall, AttributeSets are better. The API is richer. A disadvantage of PropertySets is that there is a limit on the total amount of combined storage for names and values. I haven't checked recently, but it might still be as low as 1MB.
The AttributeHelper add-in is useful for viewing and editing.

[MjDeck]

It looks like the limit is still around 1MB. You can create more than that in memory, but an error will pop up when you try to save the document.

[DRoam]

Great, thanks for confirming that for me, Mike.

Good to know that about the iProperty size limit, too. I would imagine that's pretty hard to hit with manually-created iProperties but could potentially become a problem once automation becomes involved.

Thanks again.