plugin serials broken after 11.5 update

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

On 06/09/2009 at 17:15, xxxxxxxx wrote:

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

---------
Hi,

after some of my customers updated their R11 to 11.5, my plugin asks them for serials everytime and refuses the R11 plugin serials. Thsi is quite strange, as plugin serials are generated from the c4d base serials.

Maybe this has sth to do with the way that i check my serials ?

It's a tool plugin that checks the serial everytime it is inited. Thus if a wrong serial is written with WritePluginInfo, the serial dialog pops up. Cant see nothing wrong with that though..

I somehow have the feeling its the compare part of expected serial vs. entered serial that fails.
Maybe its bc the saved serial is a String converted to LONG and the expected serial is a LONG ?

greetings,
Daniel

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

On 07/09/2009 at 06:52, xxxxxxxx wrote:

Just an idea. Make sure if the user is running a license server to use WriteRegInfo() instead of WritePluginInfo().

cheers,
Matthias

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

On 12/09/2009 at 04:49, xxxxxxxx wrote:

Hi,

thanks for the hint. i have that switch already and the customer doesnt have licServer, so thats not it.

Now that my 11.5 arrived, i could do some more testing and found the critical line that fails in 11.5 opposed to earlier versions.

It looks like serial conversion from String to LONG for some reason always returns 0 ..

am i doing sth wrong or do i have to consider some change in the API ?

here's the code:

> <code>
> // compares given and expected serials
>      static Bool Validate(CHAR *givenSerial){          
>           // this is the one valid serial that we expect from the user
>           LONG ser = computeSerial();     
>           // the serial given by user / saved to system
>           String saved;          
>           saved.SetCString(givenSerial,SERIAL_SIZE);               
>           LONG savedNr = saved.StringToLong(NULL);          
>           
>           LONG diff = ser-savedNr;
>           if(diff==0L){
>                if(debug)GePrint("POS serial is valid!");
>                return TRUE;
>           }
>           else{
>                if(debug)GePrint("POS serial is not valid!");
>                return FALSE;     
>           }
>      }
> </code>

this code worked fine before in R9.1 - R11, but now it always fails..

greetings,
Daniel

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

On 12/09/2009 at 10:00, xxxxxxxx wrote:

Quote: Originally posted by cineast2008 on 12 September 2009
>
> * * *
>
> Hi,
>
> thanks for the hint. i have that switch already and the customer doesnt have licServer, so thats not it.
>
> Now that my 11.5 arrived, i could do some more testing and found the critical line that fails in 11.5 opposed to earlier versions.
>
> It looks like serial conversion from String to LONG for some reason always returns 0 ..
>
> am i doing sth wrong or do i have to consider some change in the API ?
>
> here's the code:
>
>
>> <code>
> // compares given and expected serials
>      static Bool Validate(CHAR *givenSerial){          
>           // this is the one valid serial that we expect from the user
>           LONG ser = computeSerial();     
>           // the serial given by user / saved to system
>           String saved;          
>           saved.SetCString(givenSerial,SERIAL_SIZE);               
>           LONG savedNr = saved.StringToLong(NULL);          
>           
>           LONG diff = ser-savedNr;
>           if(diff==0L){
>                if(debug)GePrint("POS serial is valid!");
>                return TRUE;
>           }
>           else{
>                if(debug)GePrint("POS serial is not valid!");
>                return FALSE;     
>           }
>      }
> </code>
>
>
>
> this code worked fine before in R9.1 - R11, but now it always fails..
>
>
> greetings,
> Daniel
>
>
>
>
>
> * * *

Your code will fail, as soon as the serial number exceeds 2^31 - 1 (which is the max. number for LONG). That can already happen with a 10 digit serial number.

In your case you specify a 12 digit number when calling SetCString ...

Best regards,

Wilfried Behne

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

On 12/09/2009 at 10:26, xxxxxxxx wrote:

Hi.

My serials are only about 8 digits actually, so range of LONG shouldnt be a problem ;-)

My problem is that this line

  
LONG savedNr = saved.StringToLong(NULL);   

puts a zero in savedNr, even though the string 'saved' is my valid (non-zero) serial, when printed to the console.

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

On 12/09/2009 at 10:44, xxxxxxxx wrote:

Quote: Originally posted by cineast2008 on 12 September 2009
>
> * * *
>
> Hi.
>
> My serials are only about 8 digits actually, so range of LONG shouldnt be a problem ;-)
>
> My problem is that this line
> <CODE>
> LONG savedNr = saved.StringToLong(NULL);
> [\CODE]
> puts a zero in savedNr, even though the string 'saved' is my valid (non-zero) serial, when printed to the console.
>
>
> * * *

I'd guess your problem is this line:

> Quote: __
>
> * * *
>
> <CODE>
> saved.SetCString(givenSerial,SERIAL_SIZE);    
> [\CODE]
>
>
> * * *

I checked it with serial sizes up to ten digits (#define SERIAL_SIZE 10) and it works. If StringToLong() delivers 0 (you should also check the err value instead of setting a NULL pointer), your String has exceeded that size (e.g. char string not properly terminated or trashed) or isn't a number (e.g. digits mixed with alpha numericals).

Best regards,

Wilfried Behne

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

On 12/09/2009 at 11:45, xxxxxxxx wrote:

ah yes, i think thats it.

while my serials are about 8 digits, SERIAL_SIZE was still at 12 (from the sdk example).

Thus there were probably some non-number digits in it, causing stringToLong to fail.
didnt have a prob with that before 11.5 tho..

greetings,
Daniel