4.5.2.3546

[jsmorley]

builds.rainmeter.net/Rainmeter-4.5.2.3546-prerelease.exe

Change to how characters other than a-z A-Z 0-9 are handled in measure names.

It has come up that having a character other than the standard English alphanumeric characters at the beginning of a measure name can cause errors when those measure names are used in IfCondition tests and the Formula option in a Calc measure.

Those are cases where the measure name is NOT used as a [SectionVariable] which has always worked fine, and still does. It is when the measure name is used in those two cases of a "formula", where they are used without the [brackets].

This doesn't work but should..

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]

[@MyMeasure]
Measure=String
String=50
MinValue=0
MaxValue=100

[MeasureLogIt]
Measure=Calc
Formula=@MyMeasure
IfCondition=@MyMeasure <= 19
IfTrueAction=[!Log "Value is less than 19"]
IfCondition2=(@MyMeasure > 19) && (@MyMeasure < 23)
IfTrueAction2=[!Log "Value is between 20 and 22"]
IfCondition3=@MyMeasure >= 23
IfTrueAction3=[!Log "Value is greater than 22"]

[MeterDisplay]
Meter=String
MeasureName=@MyMeasure
FontSize=15
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1

That currently causes errors in both the Formula and IfCondition options on the Calc measure.

This does work...

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]

[MyMeasure]
Measure=String
String=50
MinValue=0
MaxValue=100

[MeasureLogIt]
Measure=Calc
Formula=MyMeasure
IfCondition=MyMeasure <= 19
IfTrueAction=[!Log "Value is less than 19"]
IfCondition2=(MyMeasure > 19) && (MyMeasure < 23)
IfTrueAction2=[!Log "Value is between 20 and 22"]
IfCondition3=MyMeasure >= 23
IfTrueAction3=[!Log "Value is greater than 22"]

[MeterDisplay]
Meter=String
MeasureName=MyMeasure
FontSize=15
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1

The root of this is in the "math parser" that is a part of Rainmeter. The issue is that the math parser recognizes all the math "symbols' that are used in formulas, and recognizes the "letters" alphanumeric characters a-z A-Z 0-9, but treats all other characters as "unknown", and this can, in some cases, cause an error.

Change: We have changed this so pretty much all characters that are NOT math "symbols" are treated as "letters", which we believe will solve this problem.

So the new "rule" for naming measures will now be:

- Measure names may start with or contain any "letter/number" characters or "punctuation", as long as they do NOT contain a character defined as a math symbol. Those math symbol characters are:

+ - / * ~ ( ) < > % $ ? : = & | ^

Never use those math symbols ANYWHERE in a measure name. It is a guaranteed error.

- Measures names probably should NOT contain the characters [ #, which may cause general confusion with [SectionVariables] and #Variables#.

- Measure names may NOT start with any Unicode "symbol" or "emoji" characters, like ↑ or for instance. Only use "letter/word" characters, in any language. For instance ش, 磨, 女, Æ or Щ are fine.

- Measures names may NOT start with any Unicode "space" characters, like  , an EM SPACE in the Unicode set. Rainmeter will ignore and throw away any leading normal spaces, (and tabs) but will raise an error if those Unicode spaces are used.

- Measure names may NOT start with any ASCII "control" characters, those defined as being below "32" in the decimal ASCII character set.

So the long and the short of it is that measures names can start with or contain any printable letter, number or non-math punctuation or symbol from the ASCII / Extended ASCII character set, and any Unicode "letter/word" character from any language. Stay away from everything else...

https://www.ascii-code.com/

This new "rule" really applies to all section names, but is only relevant with measures names, which can be used in IfCondition and Formula.

It is not my intention to actually document all of that, as it is kinda confusing (if not TLDR overwhelming) and I think the current general advice not to use other than normal alphanumeric characters is good enough, but that will be the new "technical rule".

It allows me to keep my [@CurrentTemperature] syntax for the @Include measures in my weather skin...


We want you guys to help us beat this up, to be sure there isn't bleed-over effect that causes problems when non-alphanumeric or Unicode characters are used in measure names or variable names, and then used in (formulas) in various places. Again, this change should only impact "math related" functionality.

[SilverAzide]

Just checking a couple minor details... I noticed the list of math symbols doesn't include minus (-). Is that intentional or an accidental omission?

Secondly, does this rule also apply to variable names, or are we just talking measures? I ask because a lot of HWiNFO skins use variable names patterned after the HWiNFO sample skin that comes with the plugin; as in #HWiNFO-CPU0-SensorId#.

[jsmorley]

Just checking a couple minor details... I noticed the list of math symbols doesn't include minus (-). Is that intentional or an accidental omission?

Secondly, does this rule also apply to variable names, or are we just talking measures? I ask because a lot of HWiNFO skins use variable names patterned after the HWiNFO sample skin that comes with the plugin; as in #HWiNFO-CPU0-SensorId#.

Accidental, and fixed above. Thanks!

As to #Variables#, I suspect it doesn't apply to them, as they don't "start" with any offending characters when "used", and in any case are "resolved" before they are ever passed to the math parser. I'm betting you can pretty much use any printable character in a variable name. This is all about the "math parser".

This pretty much just matters to measure names, and pretty much only when used in IfCondition / Formula, where they are not enclosed in [brackets]. Having them be [SectionVariables] when used seems to already bypass the problem.

[Brian]

... and pretty much only when used in IfCondition / Formula, where they are not enclosed in [brackets].

This is correct. This bug fix was only applied to the internal Rainmeter math parser, and only affects non-bracketed measure names in Calc's Formula option and IfCondition's as jsmorley stated above.

-Brian

[SilverAzide]

My limited testing feedback on this change is that Calc measures with formulas referencing the weather.com template measures that previously required brackets like [@Measure] -- or even [@Measure:] (to force a numeric value for disabled webparser children???) -- are now working perfectly well for me with the standard @Measure syntax.

[jsmorley]

My limited testing feedback on this change is that Calc measures with formulas referencing the weather.com template measures that previously required brackets like [@Measure] -- or even [@Measure:] (to force a numeric value for disabled webparser children???) -- are now working perfectly well for me with the standard @Measure syntax.

Great. As I have said, it does no "harm" to use [SectionVariables] and DynamicVariables=1, but not having to does save one line of code per measure, and in theory is just the slightest tad more efficient.

[jsmorley]

Thanks for the testing! New 4.5.3 version is released.