[BUG?]Escaping nested variables doesn't work

[death.crafter]

When I use [#*someVar*] to escape a variable it doesn't work and value of soeVar is used instead. E.g. :

Code: Select all

[Variables]
someVar=xyz

[Image]
Meter=Image
H=20
SolidColor=202020
LeftMouseUpAction=[!WriteKeyValue TextMeter Text "[#*someVar*]"][!Refresh]

[TextMeter]
Meter=String
Text=mno
FontColor=FEFEFE

It makes Text=xyz instead of Text=[#someVar].

Is this result expected or bug?

#*someVar*# works fine tho.

[jsmorley]

I'm not sure what you are seeing...

When you click on the Image meter (which needs a W option by the way, or it is a "singularity" that you can't click on) the written value of the Text option is indeed changed to Text=[#someVar], which is exactly what you asked for. That is then resolved when the skin is refreshed to xyz, which is the value of the variable #someVar#. Don't be fooled by the display of xyz at the end, the value of the Text option is certainly changed to Text=[#someVar] in the .ini file.

After I click on the image...

Code: Select all

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

[Variables]
someVar=xyz

[Image]
Meter=Image
H=20
W=20
SolidColor=202020
LeftMouseUpAction=[!WriteKeyValue TextMeter Text "[#*someVar*]"][!Refresh]

[TextMeter]
Meter=String
Text=[#someVar]
FontColor=FEFEFE

If you didn't "escape" the nested variable when you passed it in the bang, if instead you set Text to [#someVar], then the resolved value of #someVar#, which is xyz, would be written in the Text option, since the variable will be resolved in the bang itself. With the escape, Text is written as the literal [#someVar], which is the expected result. In either case the end display is going to be xyz, but the difference is that if you use DynamicVariables=1 on the meter, and later change using !SetVariable the variable #someVar#, the end result will also change. If you don't escape the variable in the bang, it will be written and fixed at xyz.

Be careful about this as well...

If you have the skin .ini file open in your text editor while you run it, be sure you are using a text editor like Notepad++ or something that will react to a change to the physical file while it is open... Windows Notepad will not, because it is crap. If you have the .ini open in your text editor, run the skin, see no change in the file open in your editor, then save the file, you will undo the change.

1.jpg

[death.crafter]

I'm not sure what you are seeing...

When you click on the Image meter (which needs a W option by the way, or it is a "singularity" that you can't click on) the written value of the Text option is indeed changed to Text=[#someVar], which is exactly what you asked for. That is then resolved when the skin is refreshed to xyz, which is the value of the variable #someVar#. Don't be fooled by the display of xyz at the end, the value of the Text option is certainly changed to Text=[#someVar] in the .ini file.

After I click on the image...

In my case it's not happening. ConstChangeAction is the action I am executing.

Screenshot 2021-06-12 192317.png

Click to animate:

Screen-Recording-_06-12-2021-19-26-58_.gif

Tho I am not sure why. I am on latest Rainmeter 4.4.0.4452.

P.S.: Here if I write ConstChangeAction=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter #*VisualizerType*#]"] it works fine and changes OnChangeAction=[!CommandMeasure Crafter #*VisualizerType*#]

[jsmorley]

Really not sure. Works fine for me...

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
OnRefreshAction=[!CommandMeasure Crafter [#VisualizerType]]

[Variables]
VisualizerType=Vector

[Image]
Meter=Image
H=30
W=30
SolidColor=202020
LeftMouseUpAction=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter [#*VisualizerType*]]"]

[jsmorley]

You have to have some kind of logic battle that s_OnChangeAction is "winning", since that is not using the "escaped" version of the nested variable.

[death.crafter]

Really not sure. Works fine for me...

Umm may be I explained wrong. The action is a variable in itself.
So you can try:

Code: Select all

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=0,0,0
SkinWidth=30
SkinHeight=30
LeftMouseUpAction=[#Example1]
OnRefreshAction=[!CommandMeasure Crafter #VisualizerType#]

[Variables]
VisualizerType=Vector
Example1=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter [#*VisualizerType*]]"]
Example2=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter #*VisualizerType*#]"]

[MeterString]
Meter=String

instead.

My guess is [#*VisualizerType*] is resolved to [#VisualizerType] when Example1 is parsed. And then when used at LeftMouseUpAction [#VisualizerType] is used.

But even so, same thing should happen with #*VisualizerType*# which is not the case.

[death.crafter]

You have to have some kind of logic battle that s_OnChangeAction is "winning", since that is not using the "escaped" version of the nested variable.

s_OnChangeAction has no role to play in the current context. I can post the skin if you would like but it's kind of complex to move around find where is what.

[jsmorley]

Umm may be I explained wrong. The action is a variable in itself.
So you can try:

Code: Select all

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=0,0,0
SkinWidth=30
SkinHeight=30
LeftMouseUpAction=[#Example1]
OnRefreshAction=[!CommandMeasure Crafter #VisualizerType#]

[Variables]
VisualizerType=Vector
Example1=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter [#*VisualizerType*]]"]
Example2=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter #*VisualizerType*#]"]

[MeterString]
Meter=String

instead.

My guess is [#*VisualizerType*] is resolved to [#VisualizerType] when Example1 is parsed. And then when used at LeftMouseUpAction [#VisualizerType] is used.

But even so, same thing should happen with #*VisualizerType*# which is not the case.

Ah, right. if you do this:

Code: Select all

[Rainmeter]
Update=-1
BackgroundMode=2
SolidColor=0,0,0
SkinWidth=30
SkinHeight=30
LeftMouseUpAction=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter [#*VisualizerType*]]"]
OnRefreshAction=[!CommandMeasure Crafter [#VisualizerType]]

It works fine. What is going on in your code is that when the LeftMouseUpAction evaluates [#Example1], it resolves [#*VisualizerType*] to [#VisualizerType] as expected. That is then causing the OnRefreshAction "action" to be handed the resolved value of the variable.

I would take a look at this...

https://docs.rainmeter.net/manual-beta/variables/nesting-variables/

One difference is that when the Nesting Variables syntax is used in bangs, the values are always dynamically resolved when they are used, including in the [Rainmeter] section of the skin. This is different than the standard #VarName# syntax, which will always require DynamicVariables=1 when the value changes, and can't be dynamic in [Rainmeter]. This difference only applies to use in bangs. When used in option values, DynamicVariables=1 must still be set on the measure or meter if the value changes.

I'm not seeing anything right off that would require you to use the "nested" version of things. The nested version of variables and measures is not always the best way to go if you don't need it. Rainmeter has to do a lot more "parsing" to unpack the logic of nested stuff, and it makes it work just a tad harder.

[death.crafter]

I'm not seeing anything right off that would require you to use the "nested" version of things. The nested version of variables and measures is not always the best way to go if you don't need it. Rainmeter has to do a lot more "parsing" to unpack the logic of nested stuff, and it makes it work just a tad harder.

For a moment I had a feeling I should not have brought this up. But I am glad I did. Actually if we use:

ConstChangeAction=[!WriteKeyValue Rainmeter OnRefreshAction "[!CommandMeasure Crafter [#***VisualizerType***]]]"]

This will result as:

OnRefreshAction=[!CommandMeasure Crafter [#VisualizerType]], reason being obvious.

This should be mentioned in the escaping Nested variables section. About multiple escapes.

[Brian]

This really has to do with how many times the variables are parsed when being replaced in multiple locations than it does with "multiple escapes".

Each time a variable is parsed, if it encounters an asterisk directly after the variable "type" character AND just before the ending variable token, it tells Rainmeter to not resolve the variable, but it then removes those asterisks since it assumes the next time the variable is used is when you really want to replace the variable with its value. I hope that makes sense.

Here is an example of what I mean:

Code: Select all

[Rainmeter]
Update=-1

[Variables]
Action=[!WriteKeyValue Rainmeter OnRefreshAction "[!Log [#***Message***]]"]
Message=Hello!
PostActions=[!About][!Refresh]

[MeterTest]
Meter=String
Padding=5,5,5,5
SolidColor=111111
FontColor=FFFFFF
Text=Click Me
LeftMouseUpAction=#Action##PostActions#
MiddleMouseUpAction=[#Action]#PostActions#
RightMouseUpAction=[!WriteKeyValue Rainmeter OnRefreshAction "[!Log [#***Message***]]"]#PostActions#
DynamicVariables=1

When clicking:

1. LeftMouseUpAction:
   • Here is what is written to the ini file: OnRefreshAction=[!Log [#*Message*]]
   • Here is what the log shows: [#Message]
     
     As you can see, using a variable as a bang replacement, a regular #variable# will get parsed twice. Once when the variable is read (in the [Variables] section), and once when the option is read (LeftMouseUpAction) - resulting 1 escape sequence left.
2. MiddleMouseUpAction:
   • Here is what is written to the ini file: OnRefreshAction=[!Log [#Message]]
   • Here is what the log shows: Hello!
     
     Still using a variable (nested) as a bang replacement, the nested variable gets parsed 3 times. Once when the variable is read (in the [Variables] section), and twice when the bang is executed (MiddleMouseUpAction) - once when the "outer" variable is replaced, and once when replaced variable is replaced again - resulting in no escape sequences left.
3. RightMouseUpAction:
   • Here is what is written to the ini file: OnRefreshAction=[!Log [#**Message**]]
   • Here is what the log shows: [#*Message*]
     
     Not using the variable as a bang replacement, the variable is only parsed once, which when the bang is executed (RightMouseUpAction) - resulting in a double escape sequence.

Hopefully that makes things a little clearer. We will discuss any changes to the docs to make things more understandable, although to be clear, this only happens when using a variable as a bang replacement.

-Brian