Section variable being resolved one update later?

[Yincognito]

Sample skin:

Code: Select all

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

[Variables]
Number=1.999

[MS_Number]
Measure=Calc
Formula=1.999
RegExpSubstitute=1
Substitute="(.*)":"[MS_Number:2]"
DynamicVariables=1

[MT_AutoScale]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text="The Original Number (N) = [MS_Number:]#CRLF#Rounded Number (number) = [MS_Number:2]#CRLF#Rounded Number (string) = [MS_Number]"
DynamicVariables=1

What happens here is that [MS_Number] (i.e. the string value of the measure) becomes 2.00 (rounded using a decimal precision of 2) after one update, not instantly, despite also using DynamicVariables=1 - so the section variable is resolved after one update, not immediately. Is this supposed to happen, since if I replace the substitute line with Substitute="(.*)":"#Number#" (basically using a 'classic' variable), the variable is resolved during the same update?

Disregard what I'm trying to achieve here (and the fact that I'm calling a measure in the same measure), it's not that important in the context. What I want to know is whether the delay in updating the value of the section variable is normal, and if it is, if you have a workaround to make the section variable resolve in the same update cycle. Thanks!

[Brian]

Disregard what I'm trying to achieve here (and the fact that I'm calling a measure in the same measure), it's not that important in the context.

Actually, this is very important in this context since this is a "chicken before egg" issue.

When an option is being read (when a skin first loads, or if using DynamicVariables=1), the variables in all the options are "resolved" (except Actions, which is discussed later). This is moment when all the variables are "found" and replaced and the final "result" is "saved" for later use (whether it be in the Update cycle or elsewhere). It is a bit more complicated then that...but you get the idea. Then, when the measure/meter is updated, is when the saved "Substitute" is used.

So here is the breakdown:

1. The measure's options are read. It's value (both number and string) is 0 at this point.
2. Substitute resolves the section variable (itself) which is still 0. Essentially, the Substitute option looks like this "(.*)":"0".
3. The measure is updated which resolves the "Formula" option to 1.999. The string value now applies the Substitute (previously stored in step 2). At this moment the number value is 1.999, and the string value is 0.
4. The meter is updated.
5. The update cycle is done.

On the next update cycle, the breakdown is this:

1. The measure's options are read (because of DynamicVariables=1). The number value is still 1.999, and its string value is still 0.
2. The Substitute resolves the section variable (itself), but now uses the number value and gets rounded to 2.00. Essentially, the Substitute option is now "(.*)":"2.00".
3. The measure is updated. Formula didn't change, so the number value is the same 1.999. The Substitute is now applied to the string value and resolves to 2.00 (from step 2). This is the moment when the string value changes from 0 to 2.00.
4. The meter is updated.
5. The update cycle is done.

I hope that helps. It is basically referencing something that hasn't been updated yet, so it's 0.

Exception:
There is one exception to the rule here, and that is Actions only resolve regular #variables# when being read, and NOT section variables (this includes nested section variables)....so in essence, section variables are applied "when" the action is taken, not when read.

-Brian

[Yincognito]

Actually, this is very important in this context since this is a "chicken before egg" issue.

Thank you very much for your detailed answer, Brian - it made things clear. I realized that it had to do with the fact that I called the measure from inside the measure itself too, since when calling it from a different one there were no "delays" involved in the string changing itself to "2.00". If I understand this correctly, without the current order of doing things (which seems natural to me, now that you explained it), a Counter measure like the one below wouldn't function as it is supposed to be, since in the first update its value will be 0+1 as a result of the "chicken before egg" system - so there's actually an advantage because of that order:

Code: Select all

[MT_Counter]
Measure=Calc
Formula=(MT_Counter+1)

Thanks again for your explanation.