[BUG?] in Multiple usage of #CURRENTSECTION#

[Yincognito]

Ok. I think I made some progress on this.

Just out of curiosity, because I didn't test it yet (will do though, in a couple of moments) ... does this mean we can also get the current section value from Lua or not?

EDIT: Damn, that works as well now, in all execution stages of a measure with bangs that's using inline Lua or a "custom variable" holding (escaped) inline Lua:

Code: Select all

  cs = SKIN:GetVariable('CURRENTSECTION', 'n/a')
  print(cs)

This is gold, really.

[Yincognito]

Here is a special build for everyone to try
-Brian

Maybe this should be tested on the skin described here by Cariboudjan as well, just to make sure it works there too. That problem was related to the !Delay fix, but it also contained some CURRENTSECTION occurences, so just to be on the safe side a test on that skin would be wise to do.

That being said, when this becomes "official" and everything is stable and all, I propose that all of us here (me, ActiveColors, death.crafter) marks the threads related to this where he is the OP as solved (edit first post and choose the green check mark), as a recognition for the effort put by the Rainmeter team into fixing these issues.

[Yincognito]

Test skin for all the scenarios I had or I could think of:

SectionIndex_1.0.0.rmskin

Test.jpg

All bar the harmless initial error at refresh work fine.

[Active Colors]

Brian,
to conclude:

1. This code works
2. This code works
3. This code works
4. This code works
5. Second answer from here works
6. This code works
7. This code works
8. This code works
9. This code works

Good job!!

So far just this needs to be verified if it works with the latest special build.

[Brian]

Thanks everyone for testing this. This fix will be in the next beta.


As described in a previous thread, the fix consisted of "tracking" which section the action belongs to. Before nested syntax was implemented, regular variables used in any option were parsed and evaluated whenever the option was "read". This happens when first loading a skin, and if DynamicVariables=1 is used on the measure/meter. Section variables were also parsed and evaluated at this time EXCEPT on actions. Also, tracking the CURRENTSECTION variable at this time is easy since the measure/meter name is readily available.

Also, actions always parsed and evaluated regular variables (ie. #SomeVariable#) when the action was read - BUT, section variables (ie. [SomeMeasure]) were not evaluated at this time. Section variables were only evaluated when the action was executed.


When nested syntax was introduced, a problem came up with mixing section variables with regular variables. Like [#Variable[&Measure]]. While normal options could parse this, actions had to wait until the action was executed. By this time, the parser is no longer tracking the section name, so the current section variable was basically unavailable for (most) actions.

The fix mainly consists of tracking down all the actions that are fired from a measure/meter and setting current section name just before those actions are parsed just before the action executes.

-Brian

[death.crafter]

Thank you for taking your time to explain Brian. That made sense.

Now you can rest easy. :P

[Yincognito]

The fix mainly consists of tracking down all the actions that are fired from a measure/meter and setting current section name just before those actions are parsed just before the action executes.

-Brian

Thanks for (re)explaning things and dealing with the current section - hopefully it's once and for all.
I'll mark the threads related to this where I'm the OP as solved.