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

    R13.058 BaseSelect::GetRange()

    SDK Help
    0
    4
    354
    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 02/06/2012 at 08:33, xxxxxxxx wrote:

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

      ---------
      Howdy,

      After upgrading to the latest version of R13 (13.058), there was a change in the BaseSelect::GetRange() member function.

      The previous function was:

      Bool GetRange(LONG seg, LONG *a, LONG *b) const;
      

      ... and the new changed function is:

      Bool GetRange(LONG seg, LONG maxElements, LONG *a, LONG *b) const; // pass
       maxElements to make sure the returned values for a and b are < maxElements
       or MAXLONGl for no additional checks
      

      Is there any reason why the updated function could not have been written like this:

      Bool GetRange(LONG seg, LONG *a, LONG *b, LONG maxElements=MAXLONGl) const;
      

      ... so that those of us plugin developers who are still supporting earlier versions of Cinema 4D would still have our plugin code working without needing to rewrite it?

      Of course rewriting the code isn't all that difficult, because I can simply create a wrapper function for it:

      Bool CDGetRange(BaseSelect *bs, LONG seg, LONG *a, LONG *b, LONG maxElem=CDMAXLONG);
        
        
      Bool CDGetRange(BaseSelect *bs, LONG seg, LONG *a, LONG *b, LONG maxElem)
      {
      #if API_VERSION < 13000
      	return bs->GetRange(seg,a,b);
      #else
      	return bs->GetRange(seg,maxElem,a,b);
      #endif
      }
      

      But I'm still curious why the new parameter wasn't added to the end with a default value?

      Adios,
      Cactus Dan

      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 09/06/2012 at 08:48, xxxxxxxx wrote:

        Howdy,

        Well, as reported by a customer today, the BaseSelect::GetRange() function change causes a crash if a plugin is compiled for R13.058 and installed in an earlier version of R13.

        So, the new question now is, could this crash issue have been avoided if the updated API function had been changed to:

        Bool GetRange(LONG seg, LONG *a, LONG *b, LONG maxElements=MAXLONGl) const;
        

        ... instead of adding the parameter in the middle of the parameter list?

        Also, if I uninstall R13.058 and reinstall the older version (R13.016) and recompile my plugins with the earlier version will that cause any issues with using them in R13.058?

        Adios,
        Cactus Dan

        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 13/06/2012 at 07:09, xxxxxxxx wrote:

          I agree it's an annoyance but I guess it's just something that can always happen. I have to check if a 13.016 compiled plugin will cause any problems in 13.058.

          In the end it's one of these annoyances to be dependent on the host API and to keep your own code up-to-date.

          cheers,
          Matthias

          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 13/06/2012 at 07:31, xxxxxxxx wrote:

            Howdy,

            Well, instead of uninstalling R13.058, I reinstalled R13.016 in a different location, compiled the plugins there and then copied them to R13.058 and they seem to work properly.

            So is there a compatibility built into the API for older versions?

            Adios,
            Cactus Dan

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