UniCode features

Hi,

I'm having a little difficulty with feature values.

1. I generated a test key with a UniCode feature but I'm having trouble decoding the feature value. I'm not sure the exact coding, I used FastSpring's $name_unicode variable and the feature type was set to string in the Lime dashboard.

For non Windows, GetFeatureValue() returns the feature string as a const char * but the comment in TurboActivate.h say that this function is using wide characters.

2. GetFeatureValue( , , 0) says that a feature has a size but you don't know until you call again with the given size that in fact the feature was not set. Is that correct ? If yes, then it's a bit annoying IMHO.

Thanks

We use UTF8 everywhere. When you enter a feature name or value in the LimeLM dashboard it is stored in UTF8. In Windows TurboActivate converts this UTF8 to the Windows Wide Char (UTF16). In Linux/Mac OS X TurboActivate leaves the UTF8 feature names/values untouched.

For non Windows, GetFeatureValue() returns the feature string as a const char * but the comment in TurboActivate.h say that this function is using wide characters.

The comment is wrong. We'll fix that. For Windows it's wide chars. For Unix it's just plain old chars.

GetFeatureValue( , , 0) says that a feature has a size but you don't know until you call again with the given size that in fact the feature was not set. Is that correct ? If yes, then it's a bit annoying IMHO.

Yes, that's true. But there's no good way around that (short of adding another function "FeatureExists()"). The good news is that you can use a buffer sufficiently large and you don't need to get the required buffer size by calling GetFeatureValue("feature name", 0, 0);

Does this make sense?

I see. When I saw wide char I was thinking that Lime might be using UTF-16. I added a few lines to your example FastSpring script to convert from UTF-32 and everything seems fine now,

$name_utf8 = "";foreach($name_unicode as $key => $value) { $one_character = pack("L", $value); $name_utf8 .= iconv("UTF-32", "UTF-8", $one_character);}

(borrowed from http://www.ibm.com/developerworks/library/os-php-unicode/index.html)

> buffer sufficiently large and you don't need to get the required buffer size by calling GetFeatureValue("feature name", 0, 0);

I prefer to allocate only what's needed. If GetFeatureValue( , , 0) returned 0 when the feature was not set, wouldn't that be the same as FeatureExists() ? Maybe it's a matter of taste.

Thanks for your help, all sorted now.

I'm testing out Unicode characters as well. So, I made a product key with some fake data in a couple of fields.

Field named `first_named` like so:Ll

Field named `last_name` like so:Hlyfd

On windows, when I debug in Visual Studio I can see that my feature values are coming back from the license file correctly. However, when I print it out to the console, it prints as gibberish. I am printing it just like the example:

wprintf(L"first_name:\t %s\n", featureValue);

Is there something I'm missing when using wprintf? Again, the data does look like it's coming back correctly, but the output is still gibberish.

Everything looks fine here. Make sure you're compiling your app as Unicode. Also, make sure the field string is actually a Unicode string (a may or may not if you're using TCHAR and you're not sure what character set you're compiling your app as)

In Visual Studio, when I go to my solutions properties, and then "Configuration Properties -> General" I see "Use Unicode Character Set" Is that what you're referring to? Should I change it to multibyte?

So, after hunting around on Stack Overflow. I happened across this thread.

http://stackoverflow.com/questions/10882277/how-to-properly-print-utf8-characters-in-windows-console

The last suggestion worked for me. I had to use _setmode for the console.

At the top of my code, I include:

#include <io.h> #include <fcntl.h>

Then, at the beginning of main() I wrote:

_setmode(_fileno(stdout), _O_U16TEXT);

Now all custom license fields will print as they are recorded in the license file. Mind you, I did not have to go through any of these shenanigans on OSX. Oh, how I love windows.

Thanks for the help!