Weather Skins Not Working

[Yincognito]

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.

Yep, I was just going to compare it to the way Substitute doesn't really change the value of the measure as well. Well, it looks like I'll have to use the option on the grandchildren then. The good thing is that in my skin, due to the way I built it, there are below 50 of them, unlike in other skins (don't ask me which...) that have hundreds of them.

And of course, one way or another, it works, that's the most important thing.

P.S. Hopefully I won't get into similar issues when I pass the value of a code point decoded child (without other children) to a String measure, cause I'm doing that for forecast data, as String measures are friendlier to dynamic variables than WebParser ones (which need a command update, i.e. another polling to the site, to get them)...

[jsmorley]

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

[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

1.jpg

2.jpg

[jsmorley]

It should be fine passing the WebParser child value with DecodeCodePoints to a String measure.

[MeasureString]
Measure=String
String=[SomeMeasure]
DynamicVariables=1

Is always by its nature "asking for" the string value of that section variable, and any DecodeCodePoints and such on [SomeMeasure] will be applied.

[Yincognito]

It should be fine passing the WebParser child value with DecodeCodePoints to a String measure.

[MeasureString]
Measure=String
String=[SomeMeasure]
DynamicVariables=1

Is always by its nature "asking for" the string value of that section variable, and any DecodeCodePoints and such on [SomeMeasure] will be applied.

Yes. It worked, just made all the needed changes. Just have to remember whenever I'll edit again the skin to keep the option on the daily forecast child measure (which is the only child of the 4 that doesn't have grandchildren), as it's the last link in the chain.

All in all, great job! Many thanks for all your effort.

[jsmorley]

Great. Glad to help.

[jsmorley]

I am increasingly of the opinion that all this might be clearer if like Substitute, DecodeCharacterReference and DecodeCodePoints were "general measure options", instead being options specific to WebParser. Those latter two behave exactly like Substitute does, and might be more intuitive if they were documented in the same place.

We are still chewing on that though...

[Yincognito]

I am increasingly of the opinion that all this might be clearer if like Substitute, DecodeCharacterReference and DecodeCodePoints were "general measure options", instead being options specific to WebParser. Those latter two behave exactly like Substitute does, and might be more intuitive if they were documented in the same place.

We are still chewing on that though...

Whatever you think it's best - as I said, personally I'm ok with either option, don't know about other folks. As long as it works, all good. And sure, some note in the documentation (including how such substitutes don't actually change the value of the measures until that value is "asked for" some place else) would be positive, IMHO.

[dragon57]

I am increasingly of the opinion that all this might be clearer if like Substitute, DecodeCharacterReference and DecodeCodePoints were "general measure options", instead being options specific to WebParser. Those latter two behave exactly like Substitute does, and might be more intuitive if they were documented in the same place.

We are still chewing on that though...

For what it is worth, I am a Rainmeter coder from way back. I would prefer having those options as "general measure" as well. Makes more sense to my old coding mind.

Regardless, I'm so grateful for the continued work everyone does here. My virtual hat is off to you.

[pbutler6]

I will take a look at using 1-Day Forecast Hourly, Current Air Quality, Forecast Pollen, and maybe adding just tons of Moon and Sun data with "astro".

Thanks for all the work you're doing. Any possibility you can also include some of the Almanac data? I would certainly like to use that too.

[klgrube]

Hi! Thanks so much for working on this. I'll gladly wait until there's a good fix for this, but I wanted to clarify something . . .

Will we see a new link here for an updated version to download or will there be code we'll need to copy and paste somewhere? I'm a little uncertain about what our next step as users will be. I'm glad to wait patiently, and i completely understand what's going on. I'm just not sure what we as users will need to do. I'll keep checking back here for an update. I just need some clear instructions, whether it's to download or to copy and paste and exactly what to copy and where to paste.

Thanks again!