So for instance, the goal might be to have things like:
This creates ambiguities that simply can't be reliably parsed and understood by Rainmeter, and can't work.
Rainmeter solves this by having an alternative form of these variables. These function exactly as their normal counterparts do, but can successfully be nested.
The alternative Nesting Variables syntax
So our examples above would look like:
It is not suggested that this in any way deprecates the current style of using variables in your skin. This is an alternative way, that simply allows for nesting to be successful. Use them all the time, or use them just when needed, that is a matter of personal preference.
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.
If you are escaping a variable and need to use the nested form, the syntax is:
You can download the above examples as a .rmskin.