Descr. Res. and backward compatibility

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

On 11/07/2006 at 20:07, xxxxxxxx wrote:

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

---------
I knew that this had to be asked here eventually, but now seems like a good time (maybe even a little late - even though I'm still in beta-testing and have warned beta-testers).

It is easy enough to keep my plugin preferences backward compatible as well as my plugins' Read/Write/CopyTo using DiskLevel. Is there any way to do something similar with the Description Resources (.res, .h, .str) for my plugins?

The problem here is that the user is importing content which relies upon, from there, tag and object plugins. The expectation is that the users save the imported content as C4D documents for later reuse (to avoid reimportation). As these plugins acquire new features or are fixed/changed, these saved documents start causing issues and crashes since the descriptions of the plugins are changing - as well as the source code. Simply appending the enumerations won't solve this - since lack of this data in later versions may cause issues with the updated source.

How can one do this without retaining every version of a method that has changed? And even that would be insufficient or dangerously insane if the code is necessarily modified to a greater degree.

Thanks,

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

On 12/07/2006 at 05:26, xxxxxxxx wrote:

Hi Kuro,

I know the changing res issue. I for one use the disk level to change according resource content. Save the disk level as a class member and then edit the interface in GetDDescription() (hide/unhide new things). The most important thing is that the header files don´t change ID wise. So new descriptions should always be appended to the list. That way oyu can simply ignore the old IDs and use the new ones. After quite some time, when I am sure my users are using the new features, I completely remove the old options.

Make sure that you store the disk level member in the Write() routine, otherwise you will get the new disk level once you saved the scene.

The disk level you can then also use to call "old" functions instead of the new ones.

Maybe give the user a popup at the first time that he should convert his old stuff to the new ones.

another option is also to use a different object with a different ID and simply hide the old object entry in the pluginsmenu (only for backward compatibility). I do this for my DPIT plugin too. It´s sometimes easier and faster than trying to figure out how to stay compatible.

Hope that helps

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

On 12/07/2006 at 07:53, xxxxxxxx wrote:

Hello Katachi,

Thank you very much for a rational approach here. I too had considered the idea of using new object/tag plugins with new IDs - this may become a necessity when moving from a v1.0 to v2.0 (and just allow multiple plugin versions to coexist with the unique IDs). But I like the idea of a separate 'DiskLevel' for tracking res changes, additions, and removals intermediately.

Luckily, this is beta-testing so I had not considered such implementation crucial. And beta-testers were warned that due to necessarily large changes during this time, saved documents may not work in later versions as testing progresses. Did that stop them - noooo. ;)

Thanks!

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

On 13/07/2006 at 01:27, xxxxxxxx wrote:

Quote: Originally posted by kuroyume0161 on 12 July 2006
>
> * * *
>
> Luckily, this is beta-testing so I had not considered such implementation crucial. And beta-testers were warned that due to necessarily large changes during this time, saved documents may not work in later versions as testing progresses. Did that stop them - noooo. ;)
>
>
> * * *

hihi, same here, nothing stops them once they are on a run. ;-))