[Bf-committers] Saving and retreiving custom object properties
codemanx at gmx.de
Sun Feb 23 14:19:11 CET 2014
there are different kinds of properties, see:
There are only ID-Properties internally, but ID-Props and static props
are separated from python perspective.
What you seem to use are ID-Properties, which are a set per datablock.
Get and set them like:
someObject['prop'] = 123
In contrast, static properties (bpy.types.*.prop = bpy.props.*) are
someObject.prop = 123
Don't mix it up, like:
someObject['prop'] = "foobar"
or you will get errors like:
KeyError: 'bpy_struct[key]: key "prop" not found'
AttributeError: 'Object' object has no attribute 'prop'
Due to how properties are handled internally, both "prop" properties
will conflict. You should avoid name duplicates. You can easily run into
funny behavior it seems - edit a static prop in Custom Properties panel
via Edit popup, and set value to a number or list - static prop will be
cleared and no ID property exists either!.
Submitted a bug report:
Am 23.02.2014 04:58, schrieb patrick boelens:
> Hi everyone,
> I've been asked to revisit an old addon I did and make it up-to-date, and in doing so I noticed something. While object properties are saved with the .blend, they are only accessable through a key, and no longer as a property of that object. Is this intended behaviour? If so, is there a reason for this? It seems a bit counter-intuitive imho. Here's an example of what I mean:
> - Open Blender
> - Enable addon
> - Perform an addon function and set "someObject.prop = 5"
> - Request "someObject.prop"
> - Returns 5
> - Save .blend and close Blender
> - Reopen, re-enable addon and request "someObject.prop"
> - Returns property not found error
> - Request "someObject['prop']"
> - Returns 5
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers