Nesting confusion

[qwerky]

No, not how to nest confusions, but rather confusion about nesting.

So, I began with example code like this:

Code: Select all

[msrUpdate]
Measure=Calc
UpdateDivider=-1
DynamicVariables=1
Formula=-1
IfConditionMode=1
ifCondition=(#CURRENTSECTION#>=1) && (#CURRENTSECTION#<=10)
IfTrueAction=[!SetOption mtrLED[&#CURRENTSECTION#] X "#penLED[&#CURRENTSECTION#]X#"][!SetOption mtrLED[&#CURRENTSECTION#] Y "#penLED[&#CURRENTSECTION#]Y#"][!UpdateMeasure #CURRENTSECTION#]
ifCondition2=#CURRENTSECTION#=11
IfTrueAction2=[!SetVariable LEDShape "#penLEDShape#"][!UpdateMeasure #CURRENTSECTION#]
ifCondition3=#CURRENTSECTION#=-1
IfTrueAction3=[!SetOption #CURRENTSECTION# Formula "(#CURRENTSECTION#+1)%12"][!UpdateMeasure #CURRENTSECTION#]

The load/refresh update sets up the formula, after which the measure is only updated from other actions. When updated, it cycles through ten times, setting up the X and Y options of ten meters, named mtrLED1 through mtrLED10. The values are set according to twenty constants (static variables) named penLED1X, penLED1Y through penLED10X, penLED10Y.

On the eleventh iteration, it sets the shape variable used by those meters. The twelfth iteration stops the loop. This all worked as expected.

Next, variations were added by using nested variables, so that the X,Y coordinates, as well as the shape, could be changed based on a pendulum name. So the shape, rather than being static, would be:
[!SetVariable LEDShape "#pen#pendulumName#LEDShape#"]
and the coordinates would be:
[!SetOption mtrLED[&#CURRENTSECTION#] X "#pen#pendulumName#LED[&#CURRENTSECTION#]X#"]
Those of course don't work. But there are nesting forms of the variables which do work. Experimentation showed that:
[!SetVariable LEDShape "#pen[#pendulumName]LEDShape#"]
where just the added "pendulumName" portion used the nesting form, did not work. What did work was using the nested form for all parts:
[!SetVariable LEDShape "[#pen[#pendulumName]LEDShape]"]

But strangely, for the coordinate options, simply using the nested form on the added pendulumName portion was sufficient:
[!SetOption mtrLED[&#CURRENTSECTION#] X "#pen[#pendulumName]LED[&#CURRENTSECTION#]X#"]
This works, without having to use the nested form on the entire variable.

The net result is that simply by setting a name variable and updating this measure, one can set all of the positions and shapes for a group of meters, to one of many variations. In fact, the eleventh iteration can set not only the shape, but also borders, colours, and many other parameters as well.

Now the question is this: why does one variable need nested versions for all portions, while another needs the nested version for only a single portion?

[Yincognito]

Related to my question, maybe?

[Brian]

Now the question is this: why does one variable need nested versions for all portions, while another needs the nested version for only a single portion?

It's a bit hard to explain, but it has to do when the option is read vs. when it is used. In general, most variables are "resolved" when the option is read. The only exception are actions, in which the variables are resolved when the option is executed. There are even exceptions to this, like regular #variables#, which are always resolved when the option is read....not executed.

We briefly discuss this on the nested variables (2nd paragraph under "Notes"): https://docs.rainmeter.net/manual/variables/nesting-variables/

In essence, when the bang is read, the regular #variables# attempt to resolve, when the bang is used, the [#section variables] attempt to resolve...and in this case, since the bang was !SetOption/SetVariable, when the "new" variable/option is read, it goes through the same process of resolving variables. It's like running through the variable replacement code several times. This most likely won't work with other bangs.

We highly recommend that when nesting any variables, to use the nesting syntax instead of the regular syntax.

Related to my question, maybe?

Slightly related, but different.

-Brian

[Yincognito]

The only exception are actions, in which the variables are resolved when the option is executed. There are even exceptions to this, like regular #variables#, which are always resolved when the option is read....not executed.

Good to know. I believe this also explains why a variable uses its "old"/unmodified value in the subsequent bangs after a [!SetVariable ...] bang, if all those bangs belong to the same action (i.e. they are on the same row). I often had to distribute the bangs in more than one meter/measure, to give Rainmeter time to update the variable to the "new" value after using !SetVariable.

[qwerky]

We highly recommend that when nesting any variables, to use the nesting syntax instead of the regular syntax.

Thanks for taking the time to explain, and for the advise. I will spend a little time to clean up my code, so that all portions are using nesting syntax, where nesting occurs.

[qwerky]

Good to know. I believe this also explains why a variable uses its "old"/unmodified value in the subsequent bangs after a [!SetVariable ...] bang, if all those bangs belong to the same action (i.e. they are on the same row). I often had to distribute the bangs in more than one meter/measure, to give Rainmeter time to update the variable to the "new" value after using !SetVariable.

Yes, after experiencing those same issues, I just took it for granted that one needs to use multiple measures/meters to obtain the new value--unless the original measure is updated, of course. (Or there may be other workarounds that I am not aware of.)

[Yincognito]

Yes, after experiencing those same issues, I just took it for granted that one needs to use multiple measures/meters to obtain the new value--unless the original measure is updated, of course. (Or there may be other workarounds that I am not aware of.)

I find this behavior logical, because those bangs are executed as a "group" in an action/option, despite them performing different tasks - or at least that's how I see it. You just have to be wary of such minor inconvenients when working with variables and wanting to use their new value right away in the bangs after, in the same action/option. Of course, sometimes you forget about it and get a bit mad trying to figure out why the heck things don't work out as planned, LMAO.

Actually, there is another workaround for this, besides distributing bangs in more than one meter/measure: use a measure instead of a variable. Unlike a variable, you can control and "force" the measure to update right away with an !UpdateMeasure before starting to use its new value, even if it's in the same action/option as the following bangs. Of course, using variables often looks more "natural" (and they are a bit easier to nest, especially in meter/measure names), so I use a measure instead of a variable only when the above issue is critical (e.g. when it's absolutely needed to have the new value available in the following bangs from the same action).

[qwerky]

I find this behavior logical, because those bangs are executed as a "group" in an action/option, despite them performing different tasks - or at least that's how I see it. You just have to be wary of such minor inconvenients when working with variables and wanting to use their new value right away in the bangs after, in the same action/option. Of course, sometimes you forget about it and get a bit mad trying to figure out why the heck things don't work out as planned, LMAO.

Perhaps I'm wrong (hope not; it's only April ), but it seems the same caveat applies even in following actions of the same measure?

Actually, there is another workaround for this, besides distributing bangs in more than one meter/measure: use a measure instead of a variable. Unlike a variable, you can control and "force" the measure to update right away with an !UpdateMeasure before starting to use its new value, even if it's in the same action/option as the following bangs. Of course, using variables often looks more "natural" (and they are a bit easier to nest, especially in meter/measure names), so I use a measure instead of a variable only when the above issue is critical (e.g. when it's absolutely needed to have the new value available in the following bangs from the same action).

Yep, agree with this.

[Yincognito]

Perhaps I'm wrong (hope not; it's only April ), but it seems the same caveat applies even in following actions of the same measure?

Yeah, I think you're right, as far as I remember. So, in the end, it's like you said: variables are updated to the new values when the measure where the actions are attached to updates as well. Good point, by the way.

[qwerky]