The standard way to delete a subhierarchie is:
* you have a single call to "manage_delObjects(ids)". It deletes the subtrees rooted in "ids".
* you customize "manage_beforeDelete" when you need special operations before the object is deleted.
Ahhh, thank you for that. I had originally thought of doing that, but then I wasn't sure if just that object was deleted (with the subobjects remaining, but not attached). But now that I think about it, since the subobjects are just 'variables' inside the top object, they would, and should be deleted.
So, to me this looks like your standard recursive function (well, sort of). However, when I get to the bottom of the tree, context.objectIds contains siblings, not children. I would expect that if there were no children, objectIds would return []. It depends on the base classes inherited by your product class.
In my view, it is a bug that "SimpleItem.Item" implements Object Manager methods (it is not such a thing!).
You, on the other hand, would like that and apparently got a base class that does not define these methods.
Which is strange to me, because when I setup the ZClass, I had it inherit from ZObject, and ZObjectManager. Ummm, now that I look again, it is ZFolder. But it should define those methods? Gosh, I'm still hazy why an object that inherits from ZObjectManager should return siblings (which it should not know about) when objectValues() was called? Andy
Dieter