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

    C++ SDK Documentation Update for R17

    SDK Help
    0
    11
    1.0k
    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

      On 03/07/2016 at 13:49, xxxxxxxx wrote:

      I would advise everyone to clear their web cache before looking at the new documentation otherwise the menus on the left will be completely wrong.

      Its all looking great. Looking forward to seeing more examples.

      Also, where is the documentation for R18?

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

        On 04/07/2016 at 00:09, xxxxxxxx wrote:

        Thanks, Kent. I'll add a note on the browser cache to the blog entry.

        On R18: Patience a gift is, young padawan.

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

          On 09/08/2016 at 06:07, xxxxxxxx wrote:

          Hello C++ community,

          in parallel to the release of Cinema 4D R17 SP3 (17.053) the C++ SDK documentation has been updated[URL-REMOVED] once more.

          Here is the changelog.

          As always the new docs are available for browsing online and as downloads in HTML format[URL-REMOVED] and Windows HTML help format (.chm)[URL-REMOVED].


          [URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

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

            On 09/08/2016 at 07:40, xxxxxxxx wrote:

            "The \__LEGACY_API define is no longer available"

            Does this mean that plugins written with things like Long & Real will no longer work?

            -ScottA

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

              On 09/08/2016 at 07:47, xxxxxxxx wrote:

              Scott, yes that's what it means. But you can copy the R16 legacy.h file into
              your project and include it.

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

                On 09/08/2016 at 08:25, xxxxxxxx wrote:

                By the way, that's nothing that changed with the current update to 17.053, but happened already, when R17 got released.

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

                  On 09/08/2016 at 08:38, xxxxxxxx wrote:

                  That sucks. But I guess it was inevitable.

                  -ScottA

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

                    On 11/08/2016 at 08:18, xxxxxxxx wrote:

                    Originally posted by xxxxxxxx

                    "The <code>__LEGACY_API</code> define is no longer available"Does this mean that plugins written with things like Long & Real will no longer work?-ScottA

                    I just recently got rid of the legacy API, i.e. using all the new typenames.

                    For older c4d versions I support, I added a compatibility layer. Mostly typedefs for the new names. Some defines for gNew, gDelete etc...

                    #pragma once   
                      
                      
                    #if PLUGIN_C4D_VERSION < 1500   
                      
                    typedef LONG Int32;   
                    typedef ULONG UInt32;   
                    typedef LLONG Int64;   
                    typedef LULONG UInt64;   
                    typedef VLONG Int;   
                    typedef VULONG UInt;   
                    ...   
                      
                    #define NewObjClear(x, ...) gNew x(__VA_ARGS__)   
                    #define DeleteObj(x) gDelete(x)   
                      
                    #define SetInt32 SetLong   
                    #define SetFloat SetReal   
                      
                    ...
                    

                    You get the idea. Can share the whole thing if you want.

                    edit: How to avoid all these extra lines in code blocks?

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

                      On 11/08/2016 at 09:10, xxxxxxxx wrote:

                      I think I'm misunderstanding how this legacy API stuff works.
                      If I write a plugin using R13. That version uses things like LONG & Real. But AFAIK this plugin will still work in R17.
                      So I'm guess that the dropped legacy stuff is only a concern if I'm writing a plugin in R17+.
                      Is that correct?

                      Basically, I'm concerned about whether or not plugins written and compiled in R13 will continue to run in R17 & R18.

                      -ScottA

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

                        On 12/08/2016 at 02:25, xxxxxxxx wrote:

                        Hi Scott,

                        yes, in most cases a 64-Bit plugin compiled against R13 SDK will still work in R17 and also R18.
                        Even though we do not recommend this, we still try to maintain binary compatibility as much as possible.

                        It were mainly naming changes introduced with R15 (as you can also see in fused's legacy header), so for example the change from LONG to Int32 involves no change in binary, the underlying integer is still the same. But with the new naming you can rely on the width of the integer on all platforms.

                        And yes, you will need to pay attention to these name changes only, if writing and compiling plugins against R15+ SDKs (with the option to keep the old style via __LEGACY_API define in R15 and R16).

                        @fused: Regarding extra lines in code blocks. I do have no issues with this here, posting from a Windows machine. Are you using a Mac? In general, I think, it's related to different line ending styles on the various platforms (and the good old forum not correctly caring for these). Using some decent editor with configurable line endings could help solve these issues.

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