CTrack::GetCurve() in 10.5 crashes

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

On 26/04/2008 at 09:52, xxxxxxxx wrote:

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

---------
Hi,

as learned, the CTrack::GetCurve() function has got a new parameter bCreate, that makes calls from a R10-compiled plugin version crash on Windows (no problems on MacOSX).

c4d_canimation.h in 10.5 resources defines

CCurve *GetCurve(CCurveType type=CC_CURVE,Bool bCreate=TRUE)        { return CaCall(GetCurve)(type,bCreate); }

in 10.x it is defined as

CCurve *GetCurve(CCurveType type=CC_CURVE)        { return CaCall(GetCurve)(type); }

Any ideas for a workaround, so that it can be compiled with R10? Thanks.

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

On 26/04/2008 at 10:24, xxxxxxxx wrote:

I have no problems with:

CCurve* curve = track->GetCurve();

on either version (R10 or R10.5).

I'd just not use the alternative GetCurve(type) as there is only one curve per track and it is only of one type. Most likely, if Maxon adds other curve types, it will be in R11 and we'll all need to do some recoding. ;)

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

On 28/04/2008 at 04:19, xxxxxxxx wrote:

Thanks.

>> I have no problems

Are you sure? Have you tested a R10-plugin with this call under C4D R10.5 on Windows? I also use track->GetCurve(); without any parameter...

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

On 28/04/2008 at 08:29, xxxxxxxx wrote:

No, I make a separate build for R10 and R10.5 because of changes in the SDK. ;) But the same animation code works on both builds.

With respect to animation, this is the only change between R10 and R10.5 in my code (in red) :

#ifdef     C4D_R10
     #ifdef     XCODE
          enum
          {
               ID_ANIM_PLA               =     100004812L
          };
          #include "ckpla.h"
     #else
          #include "newman\res\c4d_symbols.h"
          #include "newman\res\description\ckpla.h"
          #ifdef     C4D_R105
               #define     ID_ANIM_PLA          CTpla
          #endif
     #endif
#endif

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

On 29/04/2008 at 02:37, xxxxxxxx wrote:

Thanks for your reply. In my code, there isn't any change to do! I just have to recompile the project under R10.5 and that's it. BUT: this version won't run under R10 anymore. That's evident, since the sdk isn't downwards-compatible.

I'm looking for a solution that avoids an extra build for 10.5.

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

On 29/04/2008 at 08:49, xxxxxxxx wrote:

And my answer is: I don't think there is one. Almost every new release has enough changes in the SDK to require new builds - unfortunately. I sympathize as I'm in the same boat here.

My modus operandi is to let a new release build go until it is evident that something has changed and a new build is required. So far, that has definitely been the case with .0 and .5 releases.

Of course, it depends upon what features you are using and if they were changed between releases. A few plugins from as far back as R6 or R7 still work in R10 because those parts of the SDK that they utilize have remained relatively unchanged (both in the SDK itself and in the SDK code underneath). The more expanse of SDK that you utilize in your plugin the more likely the need for new builds upon new releases. My flagship plugin covers wide territory and almost always requires new builds likewise.