hachiFirstly, you'll need to pass a valid handle into the TA function calls:
uint32_t taHandle = TA_GetHandle(TA_GUID);
Then something like this:
char eraseProductKey = 0;TA_Deactivate(taHandle, eraseProductKey);
Is that what you are doing?
TA 4.0.4 TA_Deactivate() always return TA_E_INVALID_ARGS
Hi Guys,
Im in the process of passing from 3.x to 4.0.4 using the new function calls. Most of everything works fine, but I cant make TA_Deactivate() to behave like a good guy! Im always receiving a TA_E_INVALID_ARGS.
I pass the handle then a character 0. Nothing to do. I think there is something with the character thing. Im using WinDev 21, and the argument is declared as a standard apiCharacter, as it was in TA 3.x (as working well then).
So I through the question to know if something else has changed on TA side because the declaration is the same as before, except the new handle argument has been added as first argument.
Thank you for your help!Alexandre Leclerc
hachiHi hachi,
Im doing exactly that. That is why Im puzzled about the error message.
All other functions are working well with the new handle parameter. I do not think my interface is incorrect. I tried many other types of parameters and some different interface declarations. But it does not work as expected. The TA_E_INVALID_ARGS is always thrown.
Best regards,Alexandre Leclerc
Yea, in fact this was the original code I had, working from 3.x. A pure simple 0. Then I tried all else I could.
Kind regards,Alexandre Leclerc
Hey Alexandre,
We made that function more strict in version 4.x because customers were getting behavior they weren't expecting. Right now the function accepts either a 0 or a 1 (not a string, and not a character -- a byte value of a 0 or 1).
In previous versions people were passing in "0" or "1", always getting the key erased and wondering why. The reason was that the function expects an integer with a zero value or a non-zero value. And passing a "0" character is a non-zero value.
Hence the stricter behavior. Less confusion, no more unexpected results for customers.
Hi Wyatt,
Thank you for your reply.
In fact I just tried only one change I did not try: to change the API declaration from a api character to a 4-byte integer and it worked!!!
OK, no questions ask here, but it works well that way.
Thank you guys for your help.
Best regards,Alexandre Leclerc
Well, if you're not running into a problems, then that's great. But it really should be a 1-byte integer. It sounds like WinDev is re-interpreting anything passed in to a apiCharacter type -- do they have a plain old byte-type? Or an uint8_t type. Or something like that?
Hi Wyatt,
Can there be anything with Unicode? The project on which I work is handling all characters as ANSI. If the project was configured to work with strings in Unicode, it would send an Unicode character to the DLL call.
I made additional tests, and really, in TA 3.x the declaration was apiCharacter but since I switched to TA 4.0, this does not work anymore. That is why I suspected something changed a bit on the TA side. Maybe the fact that you handle the parameter in a stricter way just raised the real issue. So, the only parameter setting that works is a 4 byte integer. (I did not try 8 byte integer as it would be of no purpose.)
Best regards,Alexandre Leclerc
>> "Can there be anything with Unicode?"
No, it's about WinDev incorrectly interpreting numbers as characters. TurboActivate expects a 0 or 1 for that value. My guess is that WinDev is passing a "0" character (i.e. a number 48) or a "1" character (a number 49).
Hi Wyatt,
Spot on. I thought this was an interesting theory to test. I set back the interface declaration to an apiCharacter and I made a call forcing a Charact(0) instead of a simple 0 as before. Surprise!
WinDev is indeed converting the 0 into a 0, I guess. But sending a Charact(0) is working very well.
Best regards,Alexandre Leclerc