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' form of the variables
So our examples above would look like:
Unless you are in fact 'nesting' variables within variables, there is no other benefit to using these instead of the normal syntax. 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.
Do note however, that any use of Inline Lua in measures or meters will always require that this Nesting Variables syntax be used, as by its nature as a [SectionVariable], Inline Lua will generally require nesting of other variables or section variables in the parameters.
All the same rules for when
DynamicVaribles=1 is required where these are used still apply. Consider each component of the nested variable. If any of them require dynamic variables to successfully get the current value, then it must be used. In general, ANY nested variable that contains
[&MeasureName] is likely to require
DynamicVaribles=1 when used in measures or meters.
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.