Generator Obj: Setting NOT dirty?

Helper

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

On 11/01/2011 at 16:39, xxxxxxxx wrote:

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

---------
In cases where the user changes a setting that has no bearing (because the overall section is inactive) how would I keep the object from being made dirty (touched or whatever)? Is there a way to clear the dirty flags? Is it as simple as SetDirty(DIRTYFLAGS_0);?

Thanks!

Helper

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

On 12/01/2011 at 12:12, xxxxxxxx wrote:

Any ideas? I've tried in MESSAGE_MSG_DESCRIPTION_POSTSETPARAMETER and MESSAGE_DESCRIPTION_CHECKUPDATE from Message(). Neither of these seems to help. Or SetDirty(DIRTYFLAGS_0) isn't doing what I want.

Some might say to simply disable (using GetDEnable()) those options but the user should be able to 'set up' the section while it is inactive. This can avoid the current settings causing long regenerations or out of memory situations, for instance. But I don't want this 'set up' to cause regeneration while it is really not changing anything (not dirtying the cache).

Thanks!

Helper

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

On 12/01/2011 at 17:50, xxxxxxxx wrote:

I don't think (but also don't know) you can prevent the object from getting dirty. You changed the object's container, so the object definitely changed, hence it has to be dirty.

Maybe you could introduce a private Bool variable that indicates if the object is dirty according to your understanding. Set it in MSG_DESCRIPTION_POSTSETPARAMETER and evaluate it in GetVirtualObjects. There you just return the cache.

Helper

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

On 12/01/2011 at 22:23, xxxxxxxx wrote:

And that is exactly what I did (using MSG_DESCRIPTION_CHECKUPDATE instead).

Thanks!