Freeing coupled objects?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 06/11/2008 at 21:54, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R9-11 
Platform:   Windows  ; Mac  ;  Mac OSX  ; 
Language(s) :     C++  ;

---------
Here is the situation: I have two objects that have a hierarchical relationship:

Mother
--Son

When one is deleted the other must be deleted as well (these objects are working as a group!) - and there should be undos. When Mother is deleted, there is nothing needed to be done - the undo is stored by Cinema 4D and voila, both Mother and Son are added to the undo stack and restored on an Undo action.

But... when the Son is deleted, what? I can delete Mother in the ObjectData::Free() of Son but if I add an undo for Mother, instant crash during an Undo action (looks to be a conflict or recursion). If I don't add an undo, then nothing is undone (because Mother is not in the undo-stack).

Work that one out...

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 00:47, xxxxxxxx wrote:

Not sure I understand, you want the parent automatically deleted if the child is deleted?

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 06:25, xxxxxxxx wrote:

Yes. That's the gist of it. :)

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 08:20, xxxxxxxx wrote:

Howdy,

A couple of questions for you:

1. Is the parent object your own plugin object, too?

2. Is it possible that the user can add other objects to that parent that shouldn't be deleted?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 08:28, xxxxxxxx wrote:

1. Yes.

2. It's possible but that's their risk (which would, of course, be made known). There shouldn't be a need to child other objects to the 'Mother' as it will be a deformer object.

This won't work as one object - or, at best, it would complicate things grossly to do so (no animation, my own coordinates, no tools, etc. etc. etc.). I'm tired of reinventing C4D's wheels. Two objects in this hierarchy does exactly what I need.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 08:57, xxxxxxxx wrote:

Howdy,

OK, then here's something that might work for you:

First of all keep a running list of your plugin object that is to be the parent object. Paul Everett showed me how to do that properly, if you need some code.

Then when the child object is deleted, in it's ObjectData::Free() function, set a flag in the parent's BaseContainer marking it to be deleted.

Then create a MessageData plugin and poll for EVMSG_CHANGE and cycle through the parent object list to check for the flag.

If a parent delete flag has been set, once you've cycled through the list, call a DoUndo() to undo the child's deletion and a custom CommandData plugin that deletes the parent.

> \> if(delFlagSet) \> { \>      if(doc->DoUndo()) CallCommand(ID_DELETEPARENT); \> } \>

The CommandData should be registered with the PLUGINFLAG_HIDEPLUGINMENU flag, and not the PLUGINFLAG_HIDE flag. For some reason if you use the PLUGINFLAG_HIDE on a CommandData, you can't call the command.

In the CommandData you would cycle through the list once more to see which parent objects have the delete flag set and delete them, which in turn will also delete the child object.

You could also check to see if there are any more children that shouldn't be deleted and clone them and insert them back into the document. ;o)

I hope that helps.

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 14:21, xxxxxxxx wrote:

Eeks. ;)

I agree on the MessageData part but why all of the complexity? I simply traverse the document hierarchy (instead of keeping a running list) looking for the parent type, check the child's well-being in a Link, and, if not there, I directly did the rest of what you stated (DoUndo() and then AddUndo()/delete the parent). Works flawlessly so far.

So, flags, messages, an extra plugin CommandData, and running list seem unnecessary. I'd rather avoid the running list since in some usages (related to IPP in the future), there might be thousands of these suckers to track. :)

Thanks for the general approach!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/11/2008 at 14:58, xxxxxxxx wrote:

Howdy,

Well, that's the beauty of keeping a running list of the objects. If you have a hundred objects in the document, and only 2 of them are your plugin object, then it only checks those 2 objects in the list, rather than checking all 100 objects to see if each one is the plugin object, and then checking to see if it should be deleted. Even if you have a thousand of these plugin objects, you're only storing pointers to them in the list, so if a pointer = 4 bytes, then 1000 pointers = 4 kb). ;o)

I imagine you could do the deletions from the Message plugin. I only suggest the CommandData plugin because it might be safer from whatever thread is running when the command is called. ;o)

Adios,
Cactus Dan