Change to the SDK SetSuffix() routine in R17

On 17/09/2015 at 06:35, xxxxxxxx wrote:

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

---------
Why has the SDK SetSuffix() routine been changed in R17? In all previous versions of the SDK, SetSuffix() would append a dot and the extension string to a filename. In R17, it first removes anything up to the last dot in the filename, then adds the extension. So a filename which starts as 'anObject.1' and then SetSuffix("obj") is called in R16 or earlier, becomes 'anObject.1.obj' but in R17 it becomes 'anObject.obj'.

This makes a lot of difference if filenames are constructed based on an object's name. The object manager appends a dot and a number if more than one object with the same name is created. This means that deriving a filename from the object name will be different as long as the object name is different, but in R17 the files will all have the same name if the only difference in the object name is the dot plus number.

This didn't seem to be broken, so why fix it? And if it needed changing, why has it not been documented?

Steve

On 18/09/2015 at 03:23, xxxxxxxx wrote:

Hi Steve,

there's no change in the behavior of SetSuffix(). I tested it in R16 and it behaves exactly the same.

On 18/09/2015 at 04:28, xxxxxxxx wrote:

I have to differ, I'm afraid. I'll try to explain what happens.

In our plugin (X-Particles) we have a caching system which saves a file to disk for each cacheable object on each frame. The name of that file is constructed from the object name, plus an addition to denote the frame, padded with zeroes, then an extension which varies depending on the file format.

So if there is an object in the scene named 'xpEmitter' and this is cached, the filename for the cached frame 2, just as an example, would be 'xpEmitter_000002' and then SetSuffix("xpc") on that name makes it into 'xpEmitter_000002.xpc'. This is fine, in both R17 and earlier.

Now, if the object name in the scene is 'xpEmitter.1' then the equivalent filename would be 'xpEmitter.1_000002' and the same SetSuffix call makes it 'xpEmitter.1_000002.xpc' - note the retention of the dot in the object name. That is what happens in R16 and earlier.

BUT in R17, the main name is constructed as 'xpEmitter.1_000002' and then SetSuffix("xpc") changes it to 'xpEmitter.xpc' - the function has clearly stripped off what it thinks is an extension and substituted - not added - the 'xpc' extension. This causes the whole cache routine to fail.

I have tested this in R14 and up to R17 and there is a clear difference in the way SetSuffix() behaves in R17. The code is identical from our end, so something has changed in R17. When I say identical, this is not the same code recompiled in R17, it's the same code compiled with the R14 SDK and running in R14 and up to R17.

Possibly you didn't see any difference in your tests because the false "extension" that R17 removes is quite long - it's 8 characters - that's the only difference I can see. But difference, there most certainly is. I've been assuming that SetSuffix is an internal C4D function as it's really a string handling routine, but is it in fact calling an OS routine to do this? That might explain the difference.

Steve

On 18/09/2015 at 05:06, xxxxxxxx wrote:

Hi Steve,

I'm sorry, you are right. I used the example you gave in your first post for my tests. And you can check yourself, with that example R16 and R17 behave identical.
The reason is, that R16 only removed the old suffix, if it was no longer than 7 characters. And R17 removes it in any case.
Of course this should have been documented, but it slipped through. Sorry. On the other hand I think, the behavior of R17 is more generic. After all the length limit, you turned into your advantage, was nowhere documented.
Is it possible to replace all dots by something else on your end before setting the suffix? Another option would be to concatenate as strings and afterwards use Filename::SetFile().

Again, I'm terribly sorry for the inconvenience this caused. We are working on processes to detect such changes and get them documented (and perhaps also warn external developers upfront), but I'm sure you will agree, that this is not an easy task given the size of the entire project.

On 18/09/2015 at 06:19, xxxxxxxx wrote:

Hi Andreas,

Not a problem in the end, I solved it after I posted my initial message by treating everything as strings and converting it to a Filename when needed, just as you recommend.

Only one thing still puzzles me: we assumed there wasn't a limit on extension length, and I can't quite figure out why there would be a limit at all. So we didn't use the limit to our advantage, we naturally assumed there wasn't one since, as you say, there was nothing documented. For interest only, do you know why there was such a limit?

Steve

On 18/09/2015 at 06:31, xxxxxxxx wrote:

Hi Steve,

no, I have no idea, why there was such a limit. And in the end our development thought so as well and removed the limit. I think, replacing any existing suffix makes perfectly sense for this function.
But unfortunately this well meant thought, broke your plugin...
In a way, you indeed used this inconsistency to your advantage, as you used it in a way it was not intended. Not deliberately, of course. Don't get me wrong. No insult intended. But I guess, most other developers never found out, that you could use it to add another suffix, if the existing suffix was only long enough.
If you ask me, one probably should send Mr. Gates to jail, as the entire idea of suffixes in filenames probably cost billions all over the world by now and there were already better solutions, when they came up with this. But that of course is just my personal thought (and in no way related to MAXON) after a stressful week. Anybody loving the relicts of MS-DOS (or CP/M) should simply ignore my rant.

On 18/09/2015 at 06:51, xxxxxxxx wrote:

Always replacing the existing suffix is perfectly logical, I don't have any criticism of doing that. It was just so disconcerting to see it suddenly not working. But there we are, all fixed now.

Extensions themselves are idiotic, agreed. Would be far better to use some other way of identifying file types. Unfortunately we're stuck with them now, probably indefinitely :-(

Steve