C++ SDK Documentation Update for R17

On 01/07/2016 at 05:35, xxxxxxxx wrote:

User Information:
Cinema 4D Version:    
Platform:      
Language(s) :

---------
Hello,

many of you have requested changes to the SDK documentation.
Today we uploaded an updated C++ SDK documentation for R17.

See the announcement here.

Not saying, everything is perfect, now. Actually this is only the beginning. But the update should demonstrate the strategy for future documentation versions, we decided on.

Feedback on the new Overview/Manuals strategy would be very much appreciated.

Cheers,
your SDK Team

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?

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.

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 once more.

Here is the changelog.

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

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

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.

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.

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

That sucks. But I guess it was inevitable.

-ScottA

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?

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

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.