[Bug] Strange output from string meter when Text= contains unicode values

[phoggy]

I have a skin that is grabbing lottery results from a web page (meter=webparser) and displaying them. I noticed that the "Last draw ..." meter was displaying some numbers incorrectly when the Text= statement contains unicode values.

When this code is used ...

Code: Select all

Text=Last draw [MeasureLatestDate] [MeasureBall1] [MeasureBall2] [MeasureBall3] [MeasureBall4] [MeasureBall5] ([MeasureBallMB])

... the first 5 numbers (after "11/18/2022") are shown in ascending order, which is correct:

MM good.PNG

When this code is used ...

Code: Select all

Text=Last draw [MeasureLatestDate] [MeasureBall1] [\2022] [MeasureBall2] [\2022] [MeasureBall3] [\2022] [MeasureBall4] [\2022] [MeasureBall5] [\2022] ([MeasureBallMB])

... the 1st and 6th numbers are correct but the middle 4 numbers are in descending order, which is very odd:

MM bad.PNG

Nothing else in the skin was changed.

[eclectic-tech]

Can't replicate your issue, but a few things I can suggest:

[\0022] is not the correct format for unicode, it should be [\x0022] which will be a quotation mark "

Code: Select all

Text=Last draw [MeasureLatestDate] [MeasureBall1] [\x2022] [MeasureBall2] [\x2022] [MeasureBall3] [\x2022] [MeasureBall4] [\x2022] [MeasureBall5] [\x2022] ([MeasureBallMB])

Make sure your file is encoded as UTF16 LE in Notepad, UTF-16 LE BOM (Notepad++) or UCS-2 Little Endian (other editors) to be able to handle Unicode characters.

[ikarus1969]

[\0022] is not the correct format for unicode, it should be [\x0022] which will be a quotation mark "

The op's problem sounds weird and i can't reproduce it either.
But the code for the character in between is correct. It's the decimal form of an unicode-character with a range of 0 to 65536. The op get's the character for this code.
Op: please post the whole skin, so we can test it better.

[phoggy]

Thanks for pointing out my [\x... error. fwiw, [\2022] == [\x07E6] --> West African / Manding language character

I changed the [\2022] to [\x2022] and am seeing the correct results.

MM fixed.png

I'll post the skin later today.

[balala]

When this code is used ...

Code: Select all

Text=Last draw [MeasureLatestDate] [MeasureBall1] [\2022] [MeasureBall2] [\2022] [MeasureBall3] [\2022] [MeasureBall4] [\2022] [MeasureBall5] [\2022] ([MeasureBallMB])

... the 1st and 6th numbers are correct but the middle 4 numbers are in descending order, which is very odd:

MM bad.PNG

OMG!!! Very true.
Never even thought something like this might exist.
I can reproduce the issue. I used an extremely simple code, having a few WebParser measures:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1

[Variables]


[MeasureRainmeter]
Measure=WebParser
UpdateRate=600
Url=file://#@#Test.txt
RegExp=(?siU)<Test>(.*)</Test>.*<Test>(.*)</Test>.*<Test>(.*)</Test>.*<Test>(.*)</Test>.*<Test>(.*)</Test>

[MeasureBall1]
Measure=WebParser
Url=[MeasureRainmeter]
DecodeCharacterReference=3
StringIndex=1

[MeasureBall2]
Measure=WebParser
Url=[MeasureRainmeter]
DecodeCharacterReference=3
StringIndex=2

[MeasureBall3]
Measure=WebParser
Url=[MeasureRainmeter]
DecodeCharacterReference=3
StringIndex=3

[MeasureBall4]
Measure=WebParser
Url=[MeasureRainmeter]
DecodeCharacterReference=3
StringIndex=4

[MeasureBall5]
Measure=WebParser
Url=[MeasureRainmeter]
DecodeCharacterReference=3
StringIndex=5

[MeterNumbers]
Meter=STRING
MeasureName=MeasureBall1
MeasureName2=MeasureBall2
MeasureName3=MeasureBall3
MeasureName4=MeasureBall4
MeasureName5=MeasureBall5
X=0
Y=0
Padding=15,5,15,5
FontColor=220,220,220
FontEffectColor=0,0,0
StringEffect=Shadow
SolidColor=0,0,0,150
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
Text=[\2022] 1: [MeasureBall1] [\2022] 2: [MeasureBall2] [\2022] 3: [MeasureBall3] [\2022] 4: [MeasureBall4] [\2022] 5: [MeasureBall5]#CRLF#[\2022] 1: %1 [\2022] 2: %2 [\2022] 3: %3 [\2022] 4: %4 [\2022] 5: %5
DynamicVariables=1

The content of the #@#Test.txt file is this:

Code: Select all

<Test>2</Test>
<Test>14</Test>
<Test>16</Test>
<Test>38</Test>
<Test>66</Test>

See that additionally I added one more line in the Text option: the first one uses the names of the measures as section variables, while the second one uses the %1 - %5 parameters, refearing to the MeasureNameX options. I used the original [\2022] character. And stupor (for me at least definitely): I get the result in reverse order. A screenshot of what the above code returns:

Skin.png

see that the returned numbers are in reverse order and even more: the indexes and the appropriate number are inversed. For instance, I get 2 :1 (2 is the number returned by the measure, 1 is its index) instead of what should get, namely 1: 2.
I couldn't imagine something like this might exist. However, it does!
Replacing the [\2022] characters of the Text option with [\x07E6], I get the same result: reverse order of the result.

Comment: No more!!!

[SilverAzide]

Thanks for pointing out my [\x... error. fwiw, [\2022] == [\x07E6] --> West African / Manding language character

I changed the [\2022] to [\x2022] and am seeing the correct results.

This is not a bug, nor is it "strange", really. This set of characters is right-to-left, like Arabic and Hebrew. So when you embed this symbol into your text, it causes values to be flipped.

I'd suggest finding a different symbol to embed into your output.

[phoggy]

This is not a bug, nor is it "strange", really. This set of characters is right-to-left, like Arabic and Hebrew. So when you embed this symbol into your text, it causes values to be flipped.

I'd suggest finding a different symbol to embed into your output.

Thanks, I hadn't considered LTR/RTL or RTL embedded in an initially LTR string. Can I "buy you a coffee" ? Mea culpa for posting this in the "bug" forum.

[SilverAzide]

Thanks, I hadn't considered LTR/RTL or RTL embedded in an initially LTR string. Can I "buy you a coffee" ? Mea culpa for posting this in the "bug" forum.

No worries! If you want, you can change the title and we can move your post to a different forum.