Erasing the product key

Hello,

Sometimes, because the users (or the system) changes the clock, it can deactivate our product. It's rare but it happens.In such case, we'd like to "auto-reactivate" the product, so the user isn't bothered to do so (or worse, think that there is a major issue).

We can easily identify this case with both TA_IsActivated() and TA_GetPKey() at startup, then if needed, a simple TA_Activate() does the job.

But there is a case we need a bit more : if the user is in such a case, but at the same time already used all its activation, TA_Activate() obviously returns an error.If so, I'd like to erase the product key, so our product stops trying to "auto-reactivate". Of course, using TA_Deactivate() isn't possible here.

In brief : is there a method (outside TA_Deactivate) to erase the product key ?Thank you.

>> "Sometimes, because the users (or the system) changes the clock, it can deactivate our product. It's rare but it happens."

This shouldn't happen and we can't reproduce this. More information is needed to reproduce this. (versions, os, etc., etc.: https://wyday.com/limelm/help/faq/#useful-reports )

Are you sure you're not talking about what happens when TA_IsGenuineEx() returns TA_FAIL and more than X + Y days has passed? This is covered in the articles & examples: https://wyday.com/limelm/help/using-turboactivate/

>> "We can easily identify this case with both TA_IsActivated() and TA_GetPKey() at startup, then if needed, a simple TA_Activate() does the job."

Yeah, it sounds like the the "IsGenuineEx()" problem. Namely, not handling TA_FAIL correctly. Here's the correct solution: https://wyday.com/limelm/help/using-turboactivate-with-c-plus-plus/#handle-isgenuinex-correctly

Hello Wyatt,

Thank you for your reply.No it isn't a problem with TA_IsGenuineEx (at least from what I read from the documentation).

Our users are theaters and event companies : some machine can be activated then on the road for about 1 or 2 years. TA_IsGenuineEx() is cool, but it should be optional for us (it's more important to provide a good user service rather than protecting our app at all costs).In brief, our options for TA_IsGenuineEx are : opts.nDaysBetweenChecks = 1; // 1 day opts.nGraceDaysOnInetErr = 365*10; // 10 years ! opts.flags = TA_SKIP_OFFLINE;

Of course, we handles the result correctly :- if TA_OK or TA_E_FEATURES_CHANGED, it's ok- if TA_E_INET or TA_E_INET_DELAYED, it's still ok anyway- else it isn't ok

Probably not the best pratices, but our goal is to make the shows happen first, then protect our software.

In rare occasions, a user is contacting us, saying that he had to reactivate its software. No problem, the license server recognizes its fingerprint, but the operation makes him a bit afraid usually.We want to avoid this kind of bad user experiences : by the past (2012-2018), we reported you such problems with details, but you couldn't reproduce it, either us. So now, I'd like to look at some more pragmatic solution : the one I describe is doing the job, but I'd like to be able to clean the product key, so the behavior is even better (not trying to reactivate often in some situation).

Understanding me there : it's not the end of the world, I'm talking about a rare problem, but improving the things is always a good thing to my mind (especially in our industry, where there is a lot of tensions when the show has to play). I hope my requet makes sense.

- - - - - -

Anyway. So, is there a method (outside TA_Deactivate) to erase the product key ? Or have I to find another solution to improve my "failback" system ?

Thank you.

>> "So, is there a method (outside TA_Deactivate) to erase the product key ?"

No.

Reply
Discard post