Hi

In the new TSU9600 firmware seems to be a bug:
using System.getGlobal() to retrieve a string you have saved with System.setGlobal(), you have to be aware that the current firmware is truncating your string by a number of characters - or worse - you get an error and your ProntoScript will fail. If the string gets truncated depends on the chars in your string: chars between "\x80" and "\xFF" will obviously not be counted as chars and your string will be cut at the end by the number of chars your string contains in that specific range (I did some test scripts and verified that range as 'problematic'). Eg: if you do the following:

System.setGlobal("test_string", "blabla" + "\xf2\xf3" + "blabla");
var tmp = System.getGlobal("test_string");
System.print(tmp);

your string tmp will look like "blabla" + "\xf2\xf3" + "blab"

The last "la" get's truncated and is lost (2 chars since there is \xf2 and \xf3 in the original string). There is another problem: If the 'to be truncated' character at the end happens to be exactly in the range of those characters ProntoScript seems to forget to count ("\x80"...."\xFF"), your script will fail and ProntoScript aborts and jumps to the home activity, eg:

System.setGlobal("test_string", "blabla" + "\xf2\xf3" + "b");
var tmp = System.getGlobal("test_string"); <<<<----- this line will fail

I stumbled across this error due to the fact that my surround processor (a Lexicon) is using "\xf2" as 'end of package' sign. Since I stored all lexicon commands in global variables (I parse a lexicon configuration file in ProntoScript just once and then store all version specific Lexicon commands globally; this allows a faster restart the second time I'm calling the Lexicon activity; all of those commands have the "\xf2" at the end and nothing worked initially with v4.0.17.......). Currently my ProntoScript code is near 10'000 lines in total.....
There is a workaround: just add a number of characters to the end of the string you want to store globally (I use some space chars " ") and when retrieving, cut the " " at the end - not nice but it's working.

Would be great if someone with connections to the Philips development team will bring this forward to them. This is an ugly error. Nevertheless I really appreciate the work they all have done so far and are really thankful they brought that great piece of HW & SW to the market - it's simply the best and adding ProntoScript is an absolutely brilliant idea!

Thanks
Rene

Hi

I just implemented a small function, adding as many spaces to a string as necessary to prevent loss of data when storing a variable globally:

function Add_Space_Error(data)
{
for (i=0; i < data.length; i++)
if (data.charCodeAt(i) > 127) data += " ";
return(data);
}

If there is a binary string you want to store globally and not shure if there are any bytes between "\x80" and "xFF", just add this function before storing your data.

Eg. (for the example above):

System.setGlobal("test_string", Add_Space_Error("blabla" + "\xf2\xf3" + "blabla"));
var tmp = System.getGlobal("test_string");
System.print(tmp);

your string tmp will look correctly again: "blabla" + "\xf2\xf3" + "blabla"

This simply adds as many spaces to the string before storing as ProntoScript will cut -> bingo, my scripts are working again! :-)

Rene

Hi Rene,

I had this problem too...

Take a look:

[Link: remotecentral.com]

Hi Rodrigo

Yes, you are correct, this is the same error. The sign "°" is char 176 (decimal), equals to "\xB0" in hex and will be exactly in the problematic range of chars. Try the following (as alternative to the solution 'String.fromCharCode(176)') and simply add a space behind the degree sign:

System.setGlobal ("temperatura" , " ° ");
label = System.getGlobal ("temperatura");

and the script is working again (I just tried it myself).

For your other errors you mentioned in your post: scan your scripts for the 'setGlobal' function and correct the storing with my function above (adding the 'Add_Space_Error()' function). If the next firmware will work correctly again, you than could simply delete the two first lines in the function like this:

function Add_Space_Error(data)
{
return(data);
}

and your scripts will be working again with the firmware v4.0.17+1 (if the error will be corrected).

Either the setGlobal or the getGlobal function does not count the chars with a hex value higher than 127 and will truncate the string. Without access to the internal global memory, I really can't tell if the string is beeing truncated at the storing (setGlobal) or retrieving function (getGlobal) - I suppose it will be at the retrieving function (getGlobal) due to the behaviour if such a char is exactly at the end of the to be retrieved string -> abort and jumping to the home page. But this is just a guess of mine and a job for the Pronto team to find out definitely

Have you sent them a XCF already as Lindel suggested ?

Yes i did! But i think you have a more complete information, may be you should send your xcf to the prontoteam too...

Don't send a full-blown XCF, create one with only what is necessary to reproduce the problem and send if you like.

Ok, I just sent them a small XCF with some buttons with failing scripts. If someone could tell me how to add an attachment to a post in this forum, I would attach the XCF here also.

You can't add attachments. You have to upload to the files section.

If you are "itching" to send to someone, email it to me @ addy on profile.

I personally have asked the Team to have a look @ post #1 of this thread because I think there's a strong similarity to something I found regarding assigning play/pause/stop symbols to firmkeys.