Thank you for the link, it looks very useful!
I am dealing with an issue related to different legacy models and the way SW evolved over the time apparently. I leave this comment here as a reminder:
The feature tree has two lists of features: the feature list and the subfeature list.
They are independent from each other and former points at the latter so you must scan the tree like: first feature → first subfeature → all its subfeatures → next feature → all its subfeatures etc
Cutlist folder is a strange beast: there are three kind of tree I saw inside files made in different ways and across ten or more years with SW.
1. some files have the cutlists shown as a feature
2. some files have the cutlists shown as a subfeature
3. some files have the cutlists shown as both features and subfeatures. (same unique id in the tree is duplicated as feature and subfeature)
The reason is apparently, sometimes, the top node “Cutlists” , while visible in the model tree, it is seen as the “ordinary” (at least for parts without the welding feature in the tree) “solid bodies” folder when inquired via API.
If you are filtering the features according to getTypeName be aware of that or the type “cutlistfolder” is going to filter your real cutlist folders, because according to API it is under a non visible “solidbodies” folder in the tree root… so you have to look for “solidbodies” and its subfeatures as well. There is also a case the cutlists are in the root only and both in the root and as a subfeature of the cutlists top folder that apperas in place of the ordinary “solid bodies”…
Actually there is also a fourth case: empty cutlists folders hidden in the tree.
Those must be purged (and I posted a macro to do that) otherwise the list of cutlist folders is going to include them and since they have zero bodies inside, they will cause other issues if not managed.