THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 02:58, xxxxxxxx wrote:
It's confusing indeed, I always used GeListNode::Remove(). This is probably an error of the documentation. I will check if this is correct.
cheers,
Matthias
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 04:01, xxxxxxxx wrote:
If I would like to remove an Object, I should first remove all its children (and grandchildren...), right? And I assume that removing alone still leaves me with the responsibility to free the object afterwards, correct?
Therefor I would say that the SDK docs are rather correct in advising against it.
I now solved it by creating a selecting and calling the delete command.
Kabe
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 04:22, xxxxxxxx wrote:
In the plugin I'm just finalising, I also used the GeListNode::Remove() method. Having searched this forum I found a discussion which stated that removing a parent object would automatically remove its children, so if that's true it isn't necessary to remove all the children first. But I would really like to know if that's the case, because it makes removing and freeing an entire hierarchy so much easier.
As far as I could tell doing it this way didn't result in any memory leaks, but it would certainly be useful to have a definitive ruling on this one.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 04:30, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Having searched this forum I found a discussion which stated that removing a parent object would automatically remove its children, so if that's true it isn't necessary to remove all the children first.
Well, it actually does remove all the children - which also means that you shouldn't try to remove any of those already removed children later (this fails).
The bigger issue is how to get these out of memory: Remove() does not free the objects and the children, so don't forget to Free() them...
Hope it helps
Kabe
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 05:30, xxxxxxxx wrote:
Originally posted by xxxxxxxx
The bigger issue is how to get these out of memory: Remove() does not free the objects and the children, so IMO it's a quite save way to create massive mem leaks...
Hope it helps
Kabe
Yes, that's right - you still have to free the removed object. Question is, if you remove an object which has child objects, that does remove the child objects but does freeing the parent free the child objects as well? I can't see why it would, but having tried it there don't seem to be any leaks (unless I'm not doing it right).
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 05:33, xxxxxxxx wrote:
FYI, the note in the BaseDocument documentation applies to objects of the BaseDocument class only.
This means you are allowed to use the list methods on objects/tags/materials etc.
Removing objects still leaves you with the responsibility to free them, for instance with blDelete() or the Free() methods.
Once a document is inserted into the documents list it is currently not allowed to remove it. Documents that are only allocated but not inserted can be deleted with blDelete.
Make sure to not modify an inserted document within a running thread. For instance inserting objects into a document from within an expression tag will lead to crashes. Use for instance StopAllThreads() in CommandData plugins before any modifictation of the document.
cheers,
Matthias
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 06:28, xxxxxxxx wrote:
Unfug deleted.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 07:02, xxxxxxxx wrote:
Yes, that makes sense. I'll just have to work my way through the object list and delete them all one by one. Probably safer anyway.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 12:13, xxxxxxxx wrote:
Unfug deleted.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 15:49, xxxxxxxx wrote:
Freeing the parent object will also free its child objects.
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/04/2010 at 23:47, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Freeing the parent object will also free its child objects.
With Child objects you mean tags, animations etc.?
Kabe
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 30/04/2010 at 02:07, xxxxxxxx wrote:
no I mean child objects (which automatically includes all the other attached nodes like tags etc.). They are also freed. They are not "floating" freely like the parent object, they were inserted under the object! That´s why the object is taking care of the desctruction of them (calls their desctructors). Have you checked if the pointers remain valid? Or are they simply not NULL?
If you get child objects in GetVirtualObjects via GetHierarchyClone and this is a hierarchy, do you free all objects if there is an error? 
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 30/04/2010 at 02:50, xxxxxxxx wrote:
After thinking about it, you're right: Freeing an object does indeed free *all* children.
Stored object pointers in an AtomArray() would just point to invalid adresses for it's childs.
So when traversing the object tree, you simply get the next object before removing and freeing the object in question, and all should be fine.
Thanks
Kabe