It is currently March 19th, 2024, 5:05 am

JSMorley's Weather.com skin

Get help with creating, editing & fixing problems with skins
User avatar
jsmorley
Developer
Posts: 22632
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: JSMorley's Weather.com skin

Post by jsmorley »

1) IfCondition is like Formula in a Calc measure, and does not require that you use a measure as a [SectionVariable].

2) You don't need DynamicVariables=1 on the meter if you are changing an option with !SetOption. That bang will automatically make the destination "dynamic" for one update.

Edit: You DO need to use [SectionVariables]... There seems to be an anomaly with sections that are named starting with @ when they are used with IfCondition. I suspect it is due to the fact that there is a conflict with the @ used in "nested variables". Now I sorta wish I had chosen a different character to make those "template" measures stand out in the code...

Code: Select all

[MeasureSetColor]
Measure=Calc
DynamicVariables=1
IfCondition=[@CurrentTemperature] <= 19
IfTrueAction=[!SetOption CurrentTempRound1 LineColor "#TempColour1#"]
IfCondition2=([@CurrentTemperature] > 19) && ([@CurrentTemperature] < 23)
IfTrueAction2=[!SetOption CurrentTempRound1 LineColor "#TempColour2#"]
IfCondition3=[@CurrentTemperature] >= 23
IfTrueAction3=[!SetOption CurrentTempRound1 LineColor "#TempColour3#"]
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: JSMorley's Weather.com skin

Post by sl23 »

eclectic-tech wrote: September 18th, 2021, 5:14 pm What is the string value being reported in the log for your skin as the @CurrentTemperature?

A few errors '@CurrentTemperature' is not valid, you are checking the value of a measure,
so it should be IfCondition=([@CurrentTemperature] <= 19).

Better yet, you already defined the value of the [mNewTemp] measure in the Formula as the string value of [@CurrentTemperature]. You could use that in your IfConditions: IfCondition=([mNewTemp] <= 19)

With that change you should see the color change when the temp does, if you have DynamicVariables=1 on the Roundline meter.
Thanks et :D It was the square brackets!

Code: Select all

[mNewTemp]
Measure=Calc
Formula=[@CurrentTemperature]
MinValue=#Min#
MaxValue=#Max#
DynamicVariables=1
IfCondition=([mNewTemp] <= 10)
IfTrueAction=[!SetOption CurrentTempRound1 LineColor #TempColour1#]
IfCondition2=([mNewTemp] > 11) && ([mNewTemp] < 20)
IfTrueAction2=[!SetOption CurrentTempRound1 LineColor #TempColour2#]
IfCondition3=([mNewTemp] >= 21)
IfTrueAction3=[!SetOption CurrentTempRound1 LineColor #TempColour3#]
I changed the temperatures to see if the colour changed, and it did! Thank you for the solution :thumbup:
User avatar
jsmorley
Developer
Posts: 22632
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: JSMorley's Weather.com skin

Post by jsmorley »

This is really a bug, but not sure we can do much about it.

You DON'T normally need to use [SectionVariables] with IfCondition, just like you don't with Formula on a Calc measure. The issue you are running into here is an anomaly when a measure name starts with @, as all the measures from my weather "template" do. I'm quite sure it has to do with some conflict with parsing [@SectionName] "nested variables". I'm guessing that the @ is being discarded somewhere along the way.

Code: Select all

[MeasureSetColor]
Measure=Calc
Formula=[@CurrentTemperature]
DynamicVariables=1
IfCondition=MeasureSetColor <= 19
IfTrueAction=[!SetOption CurrentTempRound1 LineColor "#TempColour1#"]
IfCondition2=(MeasureSetColor > 19) && (MeasureSetColor < 23)
IfTrueAction2=[!SetOption CurrentTempRound1 LineColor "#TempColour2#"]
IfCondition3=MeasureSetColor >= 23
IfTrueAction3=[!SetOption CurrentTempRound1 LineColor "#TempColour3#"]
That will work just fine, without using [@MeasureName] as a section variable in the IfConditions. This is going to be a really rare issue, and I'm not sure we can easily fix it without backwards compatibility issues. We will take a look at it. Note that there is certainly no harm in using [SectionVariables] for this, just that you shouldn't have to.

Now I do wish I had chosen another character to make those "template" measures stand out in the code. I'm almost afraid to see what will happen if I try to actually use them as a "nested variable"... I should probably have used _CurrentTemperature or something.
User avatar
SilverAzide
Rainmeter Sage
Posts: 2579
Joined: March 23rd, 2015, 5:26 pm
Contact:

Re: JSMorley's Weather.com skin

Post by SilverAzide »

jsmorley wrote: September 18th, 2021, 8:26 pm That will work just fine, without using [@MeasureName] as a section variable in the IfConditions. This is going to be a really rare issue, and I'm not sure we can easily fix it without backwards compatibility issues. We will take a look at it.
Eclectic-Tech's Yahoo.com "port" of the weather.com template used dots ([.MeasureName]). I forget the reasoning for this, there was some advantage in Notepad++ he found over "@", but I forget what it was. Would this be something that would be a work-around for a future enhancement of the template?
User avatar
jsmorley
Developer
Posts: 22632
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: JSMorley's Weather.com skin

Post by jsmorley »

SilverAzide wrote: September 18th, 2021, 8:36 pm Eclectic-Tech's Yahoo.com "port" of the weather.com template used dots ([.MeasureName]). I forget the reasoning for this, there was some advantage in Notepad++ he found over "@", but I forget what it was. Would this be something that would be a work-around for a future enhancement of the template?
Yeah, at some point I will wade into all those template and skin files and change the @ to . or _ or something. Depends a bit on whether or not Brian comes back with "Oh, I can fix that"...
User avatar
SilverAzide
Rainmeter Sage
Posts: 2579
Joined: March 23rd, 2015, 5:26 pm
Contact:

Re: JSMorley's Weather.com skin

Post by SilverAzide »

jsmorley wrote: September 18th, 2021, 8:39 pm Yeah, at some point I will wade into all those template and skin files and change the @ to . or _ or something.
I kind of like "_", especially since the template is kind of reminiscent of a base class in C++/C#. But that's just me... :)
User avatar
balala
Rainmeter Sage
Posts: 16091
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: JSMorley's Weather.com skin

Post by balala »

jsmorley wrote: September 18th, 2021, 8:39 pm Yeah, at some point I will wade into all those template and skin files and change the @ to . or _ or something.
But why to use any of those characters? Why not simply [MeasureName], instead of [@MeasureName], [.MeasureName] or [_MeasureName]?
User avatar
SilverAzide
Rainmeter Sage
Posts: 2579
Joined: March 23rd, 2015, 5:26 pm
Contact:

Re: JSMorley's Weather.com skin

Post by SilverAzide »

balala wrote: September 18th, 2021, 8:43 pm But why to use any of those characters? Why not simply [MeasureName], instead of [@MeasureName], [.MeasureName] or [_MeasureName]?
I really like the prefix, whatever it is. It makes using the templates so easy since every measure stands out in the About viewer and you know at a glance what measures are "yours" vs. what measures are in a template. And it especially helpful to minimize any chance of a duplicate name clash with a measure in the skin author's own code.
User avatar
jsmorley
Developer
Posts: 22632
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: JSMorley's Weather.com skin

Post by jsmorley »

balala wrote: September 18th, 2021, 8:43 pm But why to use any of those characters? Why not simply [MeasureName], instead of [@MeasureName], [.MeasureName] or [_MeasureName]?
The goal is to have the "template" measures be easily discernable from other normal measures in About / Skins.
User avatar
balala
Rainmeter Sage
Posts: 16091
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: JSMorley's Weather.com skin

Post by balala »

SilverAzide wrote: September 18th, 2021, 8:49 pm I really like the prefix, whatever it is. It makes using the templates so easy since every measure stands out in the About viewer and you know at a glance what measures are "yours" vs. what measures are in a template. And it especially helpful to minimize any chance of a duplicate name clash with a measure in the skin author's own code.
jsmorley wrote: September 18th, 2021, 8:50 pm The goal is to have the "template" measures be easily discernable from other normal measures in the skin.
Good point...
Post Reply