Not existing measure issue

[balala]

Hello everyone,

Figured out something weird, what I can't explain. Even if I post this in the Bugs & Feature Suggestions section, I'm positive this is not a bug, I'm just looking for an explanation.
Here is a simple code:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1

[Variables]
FC=1

[MeasureRainmeter]
Measure=WebParser
UpdateRate=600
Url=file://#@#File.txt
RegExp=(?siU)<Num>(.*)</Num>
StringIndex=1
IfCondition=(#FC#=1)
IfTrueAction=[!SetVariable HT2 "[MyMeasure:]"]
IfFalseAction=[!SetVariable HT2 "([MyMeasure:])"]

[MyMeter]
Meter=STRING
MeasureName=MeasureRainmeter
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=1. %1#CRLF#HT2: #HT2#
DynamicVariables=1

The content of the @Resources\File.txt file is the following one:

Code: Select all

<Num>15</Num>

This in fact has no importance.
As you can see, the IfTrueAction and IfFalseAction options of the [MeasureRainmeter] measure are setting practically the same value for the HT2 variable, with one single difference: if the FC variable is 1, the HT2 variable gets a value equal to the non-existent [MyMeasure:] measure. Setting the FC variable to 0 in the [Variables] section, makes the IfCondition false. Accordingly the IfFalseAction sets for the HT2 variable the same value, just enclosed into parentheses. Now I get an error message in the log when refreshing the skin. This is not something weird in my opinion, much more weird is that the same error message is not appearing initially, when FC variable was set to 1.
Does anyone have an explanation of this?
Thanks in advance.

[Yincognito]

Does anyone have an explanation of this?

Yes, and it's actually quite simple, IMHO:
- [MyMeasure:] is interpreted as a plain string since the measure is not found for its parameters to get the number equivalent, so no error
- ([MyMeasure:]) triggers the formula parser due to the round brackets, and since no number value replaces [MyMeasure:], the error occurs

This behavior is alluded to in the manual as well, if one reads a bit between the lines, so to speak:

Mathematical formulas must be entirely enclosed in (parentheses) to alert Rainmeter that it is a formula, unless they are being used in the Formula option of a Calc measure or in a IfCondition option, where the function is always assumed to be a formula, and the enclosing parentheses are optional.

Note: While [Measures], [SectionVariables:] and #Variables# can be used in a formula, all the components of a formula must be numeric, using only numbers, operators, functions and constants. Using .5 or .25 in a formula will cause an error. It must be 0.5 or 0.25.

At least that's how I see what happens here. If absolute certainty is desired, a developer could either confirm or deny the above.

[balala]

Yes, and it's actually quite simple, IMHO:
- [MyMeasure:] is interpreted as a plain string since the measure is not found for its parameters to get the number equivalent, so no error
- ([MyMeasure:]) triggers the formula parser due to the round brackets, and since no number value replaces [MyMeasure:], the error occurs

This behavior is alluded to in the manual as well, if one reads a bit between the lines, so to speak:


At least that's how I see what happens here. If absolute certainty is desired, a developer could either confirm or deny the above.

Alright, makes sense in a way. However still am not sure why if

- [MyMeasure:] is interpreted as a plain string since the measure is not found for its parameters to get the number equivalent, so no error

there is no error.
But definitely what seems I missed is the fact that Rainmeter recognize a mathematical formula by the enclosing parentheses, in any other place than Formula options of Calc measures and IfConditions.
Good point, thank you for this information, which otherwise I knew, just missed it this time.

[Yincognito]

Alright, makes sense in a way. However still am not sure why if

there is no error.
But definitely what seems I missed is the fact that Rainmeter recognize a mathematical formula by the enclosing parentheses, in any other place than Formula options of Calc measures and IfConditions.
Good point, thank you for this information, which otherwise I knew, just missed it this time.

No problem, I'm sure you knew of it - but yeah, sometimes wondering about these things occurs regardless.

Why would it throw an error for a string though? [MyMeasure:] is only meaningful in terms of a section variable (with or without parameters like : and such) if MyMeasure actually exists, otherwise it's just going to be (interpreted as) a perfectly valid literal string, as there's no way to tell Rainmeter whether you want an error in such cases or not.

If all these variable look alike strings would throw errors, there would be a ton of pointless errors each time you'd use either intentional (e.g. storing a bang in a variable and such) or unintentional (e.g. some other code like strings from the internet or otherwise) such parts without escaping them first. Obviously the latter can quickly become overwhelming for longer or more complex scenarios (personally, I have one such case in my skins where I needed to somehow escape things in the feed texts, but thanks to jsmorley's advice I managed to trick Rainmeter with some Unicode char in that regard).

From my POV the question, if any, would be why the error in the similar formulas, instead of ignoring the thing and just default to 0... but since it's specified in the docs and can help in debugging the skin, I guess it does have a purpose after all.

[balala]

No problem, I'm sure you knew of it - but yeah, sometimes wondering about these things occurs regardless.

Why would it throw an error for a string though? [MyMeasure:] is only meaningful in terms of a section variable (with or without parameters like : and such) if MyMeasure actually exists, otherwise it's just going to be (interpreted as) a perfectly valid literal string, as there's no way to tell Rainmeter whether you want an error in such cases or not.

If all these variable look alike strings would throw errors, there would be a ton of pointless errors each time you'd use either intentional (e.g. storing a bang in a variable and such) or unintentional (e.g. some other code like strings from the internet or otherwise) such parts without escaping them first. Obviously the latter can quickly become overwhelming for longer or more complex scenarios (personally, I have one such case in my skins where I needed to somehow escape things in the feed texts, but thanks to jsmorley's advice I managed to trick Rainmeter with some Unicode char in that regard).

From my POV the question, if any, would be why the error in the similar formulas, instead of ignoring the thing and just default to 0... but since it's specified in the docs and can help in debugging the skin, I guess it does have a purpose after all.

Thanks for all these information. Make sense now.

[Yincognito]

Thanks for all these information. Make sense now.