Is this related to FS#117 ?

Yes, we need that for an internal project (not yet as advanced as FS#117).

Andrew, what I propose in #117 is actually a reduction of what was in TP1 ;)

Supporting XDATA from 3rd party applications is the real problem.

The AppId -> code -> value structure used by DXF/DWG where 'code' is not unique does not fit well into our key / value data structures. That would require some serious refactoring for the property editor but also for transactions (undo / redo) which use properties to store the diff between two objects.

Not impossible but painful.

Thank You Andrew for taking this seriously. Looking at a DXF file, I do not see an "AppId -> code -> value" structure, but an "AppId -> [ type, value, type, value, … ]" ordered list. The specification does not talk about implementation, but about serialization. The way I understand it, in javascript lingo, these custom properties are not /properties/ of a single object, but they are an /array/ of objects. Now, that proves my previous comment wrong. Still, there is no way around refactoring, unless you want to risk incompatibilty with other, conforming DXF, DWG reading, writing applications and likely data loss (as is now, when everything just gets dropped).

PS: The application, that I want to pass such extended attributes to, does not use the typing facilities at all, but only produces string type values, ie. group code 1000. It even ignores the AppId! So for me, regarding this feature, and with some trickery, the TP was already fully functional... I will wait then. QCAD rocks all the while.

QCAD 3.4.0 has been released today. This is the first QCAD release with custom properties enabled by default. Custom properties will be used for QCAD/CAM in the future to 'tag' entities with various machine processing options (tool radius correction inside or outside, contour start, pocket processing, point is a drill hole, etc).

3rd party custom properties are supported for types 'string', 'int' and 'double' at this point.