I discovered another annoyance like the one I mentioned earlier:
Code: Select all
[Variables]
Original=blabla[w
[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255
---Measures---
[MeasureOriginal]
Measure=String
String=#Original#
UpdateDivider=-1
; The below doesn't work
OnUpdateAction=[!SetOption MeterTest Text #Original#]
; The below does work
; OnUpdateAction=[!SetOption MeterTest Text [MeasureOriginal]]
; The below does work
; OnUpdateAction=[!SetOption MeterTest Text #*Original*#]
DynamicVariables=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
Text=
DynamicVariables=1
The 3rd choice, while it works for in-skin operations, it doesn't work for intra-skin operations (like passing a value between skins), so it's useless for my usage case, where I pass such values between the parent skin and the custom tooltip one using !SetOption. Fortunately, the 2nd choice works for both in-skin and intra-skin operations, but this means I'll have to convert all my variables to String measures... all because of these little quirks in the Rainmeter parser. Damn...
Just as an idea, wouldn't some hypothetically new section variable parameter, like, say,
:SkipEvaluation solve these issues by forcing Rainmeter to discard / ignore any brackets or anything that is used to reference / express another variable, measure or formula, so that the string stays as it is and doesn't break the expected process (with or without throuwing an error, as it could be seen in the latter case)? Or, maybe something like that for both section variables and normal variables, as they both seem to be affected. By the way, adding that hypothetically new parameter wouldn't (and shouldn't) negatively affect backwards compatibilty - and should, of course, work for both in-skin and intra-skin operations. Just saying...
