This actually has nothing to do with IfCondition bangs, nested syntax or inline lua. This issue is specific to the CURRENTSECTION
variable and is caused by how/when bangs are parsed.
For action options, normal variables (ie. #Variable#
) are parsed when the option is read or updated. This happens when the skin is refreshed, during the Update cycle when DynamicVariables=1
is used, and when the !SetOption bang is performed on any option in that section. However, section variables (ie. [Measure]
) and nested variables (ie. [#Variable]
) are not parsed at this time...they are only parsed when the action is executed.
variable is the only variable that needs special parsing throughout Rainmeter, both in its regular #CURRENTSECTION#
and nested [#CURRENTSECTION]
forms. The reason is because of the different "times" when the variable *can* be parsed. Basically, Rainmeter has to keep track of not only when the action is to be performed (or where the variable was referenced), but by the section that has executed the action. In most cases, the current section is tracked, but obviously not all of them.
For example, in your case above, when the IfConditions actions are read, the #CURRENTSECTIONINDEX#
variable is replaced with [&Script:SectionIndex('[#CURRENTSECTION]','last','(<x>)')]
(note the *
's were removed in this step). Normally, the current section special processing would kick in and parse the [#CURRENTSECTION] variable here, but that does not happen since the action only re-evaluates section/nested variables when the action is executed. By that time, section tracking is lost and nothing is retrieved. This particular case seems to be related to variables referencing other variables containing the current section variable.
Here is a similar test skin that shows the CURRENTSECTION problem with a basic OnUpdateAction:
Code: Select all
OnUpdateAction=[!Log "Measure1=[Measure1]"][!Log "CurrentSection(regular)=#CURRENTSECTION#"][!Log "CurrentSection(nested)=[#CURRENTSECTION]"][!Log "var(regular)=#var#"][!Log "var(nested)=[#var]"]
Unfortunately, this current section issue has been around since we introduced the variable. Fixing it for all the special cases has been a challenge.
PS - The complicated implementation of current section variable and its special processing is the main reason why we are hesitant to introduce any indexing variable. That doesn't mean we can't find a way to do it, it just means we haven't worked out the best way to do it.
PSS - Unfortunately, the SKIN:ReplaceVariables() is another portion of the code that does not contain the current section tracking code either.