BrainModular

Can someone explain how to use the new sdkAddSettingsLineString in the SDK ?

There are 3 new functions in the new SDK:

void sdkAddSettingsLineString(AnsiCharPtr tab, AnsiCharPtr pVal, AnsiCharPtr caption, LongBool Translate = FALSE)
void sdkSetSettingValue(AnsiCharPtr settingName, UsineEventPtr settingEvent)
UsineEventPtr sdkGetSettingValue(AnsiCharPtr settingName)

sdkAddSettingsLineString
- who allocates the memory that the string is stored in, for example, should pVal be just a pointer for Usine to set up, or should it point to a buffer ? If a buffer, where is the size of the buffer specified ?

If I allocate a buffer, then the string can be modified from the Usine settings panel, but I cannot access it from within the User module, either to read the modified value in onSettingsHasChanged(), or to set the value from within the User module.

Should sdkGetSettingValue and sdkSetSettingValue be used to do this ? I have tried various things but nothing works, including this:
UsineEventPtr ev = sdkGetSettingValue(SettingsLineStringCaption);
AnsiCharPtr pointer_to_settings_string = sdkGetEvtPChar(ev);

Can we please have an example User module that does this, since it is not obvious ?

Thanks,
Simon.

OK, I've cracked it.

Usine puts a UTF-16 string at the address passed to sdkAddSettingsLineString(), rather than a normal string. Whether this is intentional, or the same on the Mac, I don't know.

Anyway, on Windows the string should be defined as like this:

wchar_t *testString;

The address is then passed to Usine in the SDK function like this:

sdkAddSettingsLineString(DESIGN_TAB_NAME, (AnsiCharPtr)&testString, "Test String");

AnsiCharPtr is actually a char* type, so strictly speaking the SDK parameter type is wrong. The SDK needs to define a new type such as AnsiUTF16CharPtr or AnsiWideCharPtr or something (which would also drop the hint to the SDK users).
The parameter type would then be "AnsiWideCharPtr *".

The string can be printed out using printf "%S" rather than "%s".

You can use the C++ wstring class to store the UFT16 string.

mm pers i just do like this:

string test_text;

sdkAddSettingsLineString("Fader", test_text.c_str(), "enter_text");

23fx23 wrote:mm pers i just do like this:

string test_text;

sdkAddSettingsLineString("Fader", test_text.c_str(), "enter_text");

OK, well thats interesting. How do you get the modified value back when the user changes the settings string ?
Do you find that the string in test_text has changed to match what the user entered ?
I will certainly try it since if that works, some C++ magic must be happening. Perhaps the string class can handle
a C string and a Unicode string automatically.

at work currently and will recheck at home tonight, but as i remember it was updating the input string variable like data pointers, did quick test tho, ll have to confirm that

Well that method doesn't work for me - 32 bit Usine on Windows. And the second time I tried it Usine crashed.

I did try it a different simpler way first, but I was only seeing the first character of the string. This was because the second byte was zero due to it being Unicode, but zero marks the end of a normal C string. When I pasted in a funny quote symbol from a Word document, the 2nd byte of Unicode was not zero. I looked up the 2 bytes in a Unicode table and it matched the character I had pasted in.

I don't know if it is Unicode intentionally, or if this changes according to a locale setting in Windows. But the normal Usine text data flow is definitely not Unicode. Of course Unicode supports an extended character set which is useful.

But the SDK does lack in documentation - so we have to find some example code, or fiddle around until it works.

I don't really care if it is Unicode or not, as long as it does not change and break my User modules !

ok sry i could swear i had it working once , but testing back, i can enter a multi char string that is saved and recalled in the workspace but indded get weird char in side the code trying to read back the string

I am just going to use this function in a module.
Perhaps Senso can confirm that the value is supposed to be a UTF-16 string and that it will not change to another type of encoding.

Simon.