Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush Python API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Unread
    • Recent
    • Tags
    • Users
    • Login

    Detecting CopyTo() Undo Stack

    SDK Help
    0
    3
    318
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      Helper
      last edited by

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

      On 14/09/2003 at 18:19, xxxxxxxx wrote:

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

      ---------
      I'd like to know when CopyTo() is being called for the Undo stack so that I can avoid copying potentially-large data I've cached (ie: whole documents).

      I'm seeing the following flag bitstrings supplied to CopyTo()

      For CopyTo Undo on parameter change:
      1010 0001 1000
      (ie: MYSTERY_FLAG | COPY_NO_HIERARCHY | COPY_NO_INTERNALS | COPY_NO_BRANCH)

      For CopyTo for particle cloning:
      0001 1000 0000
      (ie: COPY_NO_ANIMATION | COPY_NO_BITS)

      And for CopyTo Undo on delete:
      1000 0000 0000
      (ie MYSTERY_FLAG)

      So it looks like I can detect CopyTo the Undo stack using the MYSTERY_FLAG. Can I rely on this? Is it documented anywhere?

      Thanks.

      .angus.

      1 Reply Last reply Reply Quote 0
      • H
        Helper
        last edited by

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

        On 19/09/2003 at 12:21, xxxxxxxx wrote:

        There's no official undo flag, so I don't know if what you see only concerns undo. It might be something else that's only correlated. Generally it would be safer not to rely on this flag.
        What you could do is to use a reference counted pointer to the cached data instead. Then you needn't copy the whole cache each time the object is counted. (If you don't want to write it yourself you can use shared_ptr from the smart_ptr library of http://www.boost.org.)

        1 Reply Last reply Reply Quote 0
        • H
          Helper
          last edited by

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

          On 22/09/2003 at 01:03, xxxxxxxx wrote:

          I'm already using a reference-counted pointer to share data.
          But because it gets copied to the Undo stack, the ref-count never drops to zero. The data I'm caching is potentially very large (entire loaded documents), so I want to dereference the data when the object is copied to the Undo stack. IE: I don't want to continue to keep cached data for objects on the Undo stack.

          I've just noticed that in my original post, I wrote all my bitstrings backwards (LSB -> MSB)... it *should* have read as follows:

          #define MYSTERY_FLAG 1

          I'm seeing the following flag bitstrings supplied to CopyTo()

          For CopyTo Undo on parameter change:
          0001 1000 0101
          (ie: COPY_NO_BRANCH | COPY_NO_INTERNALS | COPY_NO_HIERARCHY | MYSTERY_FLAG)

          For CopyTo for particle cloning:
          0000 0001 1000
          (ie: COPY_NO_BITS | COPY_NO_ANIMATION)

          For CopyTo to/from copy buffer:
          0000 0000 0000
          (ie: no flags)

          And for CopyTo Undo on delete:
          0000 0000 0001
          (ie MYSTERY_FLAG)

          .angus.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post