BaseContainer and sub-container?



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

    On 12/12/2008 at 21:27, xxxxxxxx wrote:

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

    ---------
    Howdy,

    OK, the SDK documentation says:

    > Quote: __
    >
    > * * *
    >
    > BaseContainer GetContainer(LONG id) const
    > Returns a copy of the sub-container with the specified ID, or an empty
    > container if it doesn't exist.
    >
    >
    > * * *

    Now, in the new version of my tag, I wanted the sub-container to be at a specific ID, but that's the ID where data was located in the old version of the tag, which will no longer be used. If the tag is newly added to an object, no problem, but if a file is loaded with the old tag on an object, and I call:

    > \> BaseContainer subBC = tagData- >GetContainer(SUB_CONTAINER); \>

    ... it crashes. The above code works fine when the new version of the tag is newly added to an object, it gives me an empty sub-container, and I can successfully store data into it.

    One solution was to change the ID number of SUB_CONTAINER to an ID that was never used by the old version of the tag, BUT the question is how can I get rid of all of the old data and ID's? None of the data stored in the old tag version's container is being used at all in the new tag version.

    When an old file is loaded, I have it polling for the message MSG_MULTI_DOCUMENTIMPORTED so it can check for an older version of the tag. I was hoping to be able to get rid of the old stuff there, but I tried BaseContainer::RemoveData(), BaseContainer::RemoveIndex() and even BaseContainer::FlushAll() and nothing seems to wipe the slate clean. :o(

    The SDK documentation also says:

    > Quote: __
    >
    > * * *
    >
    > Once you've set a container value using one type you must neither try to
    > access it using another type, nor overwrite it with a value of another type!
    > Using the wrong access will not crash, but it is illegal.
    >
    >
    > * * *

    Does this also mean that once you set a container value, you can never get rid of it?

    Adios,
    Cactus Dan



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

    On 14/12/2008 at 13:38, xxxxxxxx wrote:

    No answers? I have the same problem! I store a sequence of LONG values and I would like to delete them, when the user wants to...



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

    On 15/12/2008 at 01:40, xxxxxxxx wrote:

    Sorry I can't confirm. FlushAll() seems to work fine for example:

    > \> BaseContainer bc; \> \> LONG i,j,id; \> \> for(i=1000; i<1010; i++) \> { \>      bc.SetLong(i, 1234567890); \> } \> \> j=0; \> while (TRUE) \> { \>      id = bc.GetIndexId(j++); \>      if (id==NOTOK) break; \>      GePrint(LongToString(bc.GetLong(id))); \> } \> \> bc.FlushAll(); \> \> for(i=1000; i<1010; i++) \> { \>      bc.SetReal(i, pi); \> } \> \> j=0; \> while (TRUE) \> { \>      id = bc.GetIndexId(j++); \>      if (id==NOTOK) break; \>      GePrint(RealToString(bc.GetReal(id))); \> } \>

    cheers,
    Matthias



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

    On 15/12/2008 at 07:59, xxxxxxxx wrote:

    Howdy,

    Well, all I can say is DOH! DOH! DOH!. :o(

    The problem was that my code was written like this:

    > \> case MSG_MULTI_DOCUMENTIMPORTED: \> { \>       if(DISK_LEVEL < 1) FlushOldData(tData); \> } \>

    ... when it should've been written like this:

    > \> case MSG_MULTI_DOCUMENTIMPORTED: \> { \>       if(tData->GetLong(DISK_LEVEL) < 1) FlushOldData(tData); \> } \>

    DOH!

    I can't believe I looked at that all day long and couldn't see the mistake. :o(

    Oh well, thanks for the support anyway.

    Adios,
    Cactus Dan



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

    On 16/12/2008 at 00:11, xxxxxxxx wrote:

    glad you found the problem Dan.

    cheers,
    Matthias


Log in to reply