SNHookClass curdate-regdate problem
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/06/2011 at 11:28, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R12
Platform: Windows ;
Language(s) : C++ ;---------
Hi,I have a problem using the SNHookClass with the curdate-regdate mechanism to setup a trial period with a case insensitive "demo" check.
Here is, what I investigated so far.
If I simply use the following code, any spelling of "demo" will be accepted as serial and "regdate" is set to the current date.
if (!sn.LexCompare("Demo")) { return SN_OKAY; }So the { return SN_OKAY; } triggers the registration.
But unfortunately it can be "refreshed" anytime if a variation in the spelling is entered as serial again.
e.g.: if I use "demo" the first time, I could use "Demo", "DEMO", "DemO", "DeMo", ... to reset the registration time.Also we need to check for the remaining trial period to make it expire when the time has come.
At first I tried that, the following way:
#define DEMO_TIME_MAX 14L // Trial period in days // check if serial is "DEMO" (case insensitive) if (!sn.LexCompare("DEMO")) { // Calculate demo_time_remain of demo mode LONG demo_time_remain = DEMO_TIME_MAX - (curdate - regdate); if (demo_time_remain < 0L) { return SN_EXPIRED; } if (demo_time_remain <= DEMO_TIME_MAX) { return SN_EXPIRE_14 - demo_time_remain; } return SN_OKAY; }Granted it is the first time an accepted serial was entered so the plugin wasn't registered before and regdate was "0".
The result is, that regdate is set to "0" again and the serial expired.
What happened in detail is, that regdate was set to the current date, than { return SN_EXPIRE_14 - demo_time_remain; } was executed, than regdate has been reset to 0 and so { return SN_EXPIRED; } had been executed.But if the plugin was registered before, let's say by another legal serial, so that regdate wasn't "0" when the "demo" serial was entered, regdate will stay at that registration date and also entering "demo" in a different spelling didn't set regdate to the current date (because that would require a "return SN_OKAY;") nor "0" (that would require, that regdate was "0" before). Or to be accurate in fact regdate is temporary set to the current date (it seems this always happens at first!) but will then immediately be reset back to the registration date.
So it seems the problem that regdate is reset to 0 is triggered by the "SN_EXPIRE_14" in combination with a regdate of "0" when the "demo" string is entered as serial.
I know, in the SDK docs is written:
Note: If you perform a curdate-regdate, please observe that regdate is 0 when the serial number is entered for the first time.
But what exactly does that mean?
I mean, it's clear, that regdate is 0 before a serial is entered for the first time but it mustn't be 0 after!In my opinion this is simply a bug in the Cinema 4D API and I have no idea for a workaround!
I think to make it work it would be necessary to register the "demo" with a { return SN_OKAY; } when a demo serial is entered the first time but not later if it is entered in a different spelling again.
In theory I first thought, the following would do the trick:
#define DEMO_TIME_MAX 14L // Trial period in days // check if serial is "DEMO" (case insensitive) if (!sn.LexCompare("DEMO")) { if (regdate != curdate) { // Calculate demo_time_remain of demo mode LONG demo_time_remain = DEMO_TIME_MAX - (curdate - regdate); if (demo_time_remain < 0L) { return SN_EXPIRED; } if (demo_time_remain <= DEMO_TIME_MAX) { return SN_EXPIRE_14 - demo_time_remain; } return SN_EXPIRED; } return SN_OKAY; }The idea is to avoid the trial period calculation (and so the return of SN_EXPIRE_14) on the first day of registration but return a SN_OKAY to trigger the registration mechanism. Because on the first day it is insignificant that the trial period could be reset.
Unfortunately this also doesn't work because, as I mentioned above, regdate is temporary always set to the current date if something is entered in the serial field of the personalisation dialog. And so I can't avoid to return SN_OKAY if demo is reentered in a different spelling.
So what would be a correct way to setup a trial period check for a case insensitive demo serial?
Or is this even possible with that bug in the API? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/06/2011 at 08:49, xxxxxxxx wrote:
See this thread which also discusses the problem.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/06/2011 at 09:44, xxxxxxxx wrote:
My code is now doing it like this:
// Case-insensitive serial number 'demo'
String demo = sn.ToLower();
if (demo.Compare("demo")) return SN_WRONGNUMBER;No idea if that solved the issue yet. If it does for you, please report back.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 13/06/2011 at 05:45, xxxxxxxx wrote:
Originally posted by xxxxxxxx
See this thread which also discusses the problem.
So what?
There is no working solution in that thread either.Originally posted by xxxxxxxx
My code is now doing it like this:
// Case-insensitive serial number 'demo'
String demo = sn.ToLower();
if (demo.Compare("demo")) return SN_WRONGNUMBER;No idea if that solved the issue yet. If it does for you, please report back.
Hmm, make the check reverse, I'll give it a try.
Maybe it's a way around that problem.
Not sure at the moment, I have to think about it and make a test.
But thanks.
Nevertheless, I hope perhaps Matthias can say something official about this and maybe even confirm that it's in fact a bug and will be fixed.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 13/06/2011 at 06:38, xxxxxxxx wrote:
Originally posted by xxxxxxxx
So what?
There is no working solution in that thread either.Really? The solution (if it is a solution, that's up to you to check) is the one Robert suggested in his post.