Weather Skins Not Working

[jsmorley]

Yeah, but I do update the group those measures belong to in the FinishAction of the WebParser parent...

!UpdateMeasure doesn't really do much on a WebParser measure. So instead of 600 skin updates until it performs the functionality, it's now 599 skin updates...

Just my opinion, but UpdateDivider=-1 is pretty much always a bad idea on any WebParser measure.

[Yincognito]

LOL, There is no way I'm even going to attempt to figure out that mess you have going...

Well, that "mess" just provided an alternative in parsing the weather.com data...
Joking aside, I know you're scared of my codes, LOL. Relax, I'm not going to bother you with my "hideously complicated" erm..."mess".

I was just asking if you're able to replicate the thing in a simple, basic skin, that's all.

EDIT: Just commented out the UpdateDivider=-1 from both the intermediate child and the final one. Same result.

[jsmorley]

Well, that "mess" just provided an alternative in parsing the weather.com data...
Joking aside, I know you're scared of my codes, LOL. Relax, I'm not going to bother you with my "hideously complicated" erm..."mess".

I was just asking if you're able to replicate the thing in a simple, basic skin, that's all.

Two hundred years ago you would have been burned at the stake...

[Yincognito]

Two hundred years ago you would have been burned at the stake...

Nah, I would have rebelled against the tyrants, and become a Robin Hood of some sort ... or the next emperor.

[jsmorley]

I don't think the culprit is StringIndex2 as such.

https://docs.rainmeter.net/tips/webparser-using-stringindex2/

There must be something else about this that is throwing WebParser.

and I need to change the URL that example uses. That feed is long dead...

[Yincognito]

I don't think the culprit is StringIndex2 as such.

https://docs.rainmeter.net/tips/webparser-using-stringindex2/

There must be something else about this that is throwing WebParser.

and I need to change the URL that example uses. That feed is long dead...

Understood - I'll build a basic skin and see if it happens there as well. Just to take out a possible (yet unlikely, in my view) mistake in my code.

[jsmorley]

I'd be tempted to use FinishAction on the "parent" to throw a [!CommandMeasure MeasureName "Update"] at the "intermediate" measure to see if that has any effect.

[Yincognito]

I'd be tempted to use FinishAction on the "parent" to throw a [!CommandMeasure MeasureName "Update"] at the "intermediate" measure to see if that has any effect.

Just tried it. No effect.

[Yincognito]

I don't think the culprit is StringIndex2 as such.

https://docs.rainmeter.net/tips/webparser-using-stringindex2/

There must be something else about this that is throwing WebParser.

and I need to change the URL that example uses. That feed is long dead...

Here is the simple test. This assumes there is a UCS-2 LE BOM file called SomeFile.txt in the current skin folder, having this contents:

Code: Select all

This is a unicode code point: \u0219 and this is not: u0219.

The code:

Code: Select all

[Variables]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[MeasureParent]
Measure=WebParser
URL=file://#CURRENTPATH#SomeFile.txt
CodePage=1200
RegExp=^(.*)$

[MeasureChild]
Measure=WebParser
URL=[MeasureParent]
StringIndex=1
RegExp=(?siU)^(.*) and (.*)$
StringIndex2=1
DecodeCodePoints=1

[MeasureGrandchild]
Measure=WebParser
URL=[MeasureChild]
StringIndex=1
RegExp=(?siU)^(.*): (.*)$
StringIndex2=2
;DecodeCodePoints=1

---Meters---

[MeterTest]
Meter=STRING
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=MeasureGrandchild
Text="Test = %1"
DynamicVariables=1

Result:

Code Point Grandchild.jpg

Seems like the decoding is done in the child, but somehow it doesn't persist in the grandchild, unless one adds the option to it as well...

[jsmorley]

Ah, well, that makes some sense. Much like Substitute, the DecodeCodePoints option is acting on the string value of the measure, no doubt when the string value is "asked for", and does not "change" the indexed value of the intermediate child measure. Since the URL=[SomeMeasure] option in WebParser is not "asking for the string value" of the measure in question, but internal to WebParser saying "let me use your data". I can see why DecodeCodePoints isn't going to work until you actually use the string value of the measure someplace. It is only the "grandchild" that is ever being displayed.

Don't be fooled by the log, it is "asking for the string value" of the child measure. So the DecodeCodePoints is working there. That doesn't in any way mean that the value of the child measure is actually "changed" by the DecodeCodePoints.

I don't know if it helps your situation, but you can "ask for" and use the "string value" of a WebParser measure in another WebParser measure like this:

URL=[&SomeMeasureName]
DynamicVariables=1

Just keep in mind that things like Substitute, DecodeCharacterReference, DecodeCodePoints and any another options that might be eluding me at the moment that "manipulate" the value of a measure, do NOT "change" the value of the measure. They are applied when the value of the measure is "asked for" by something else.