[BUG?] Delay bang in OnRefreshAction's nested variable

[Yincognito]

Test skin:

Code: Select all

[Variables]
DelayDuration=3000
EndMessageIdx=1
StartDelay0=
StartDelay1=[!SetOption DummyMeter SolidColor "0,0,0,255"][!UpdateMeter DummyMeter][!Redraw][!Delay #DelayDuration#][!SetOption DummyMeter SolidColor "255,0,0,255"][!UpdateMeter DummyMeter][!Redraw]
EndMessage0=
EndMessage1=[!Log "End of a #DelayDuration# ms delay"]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255
OnRefreshAction=[!Log "Start of a #DelayDuration# ms delay"][#StartDelay[#EndMessageIdx]][#EndMessage[#EndMessageIdx]]
;OnRefreshAction=[!Log "Start of a #DelayDuration# ms delay"][#StartDelay1][#EndMessage[#EndMessageIdx]]
;OnRefreshAction=[#StartDelay[#EndMessageIdx]][#EndMessage[#EndMessageIdx]]
;OnRefreshAction=[!Log "Start of a #DelayDuration# ms delay"]#StartDelay1#[#EndMessage[#EndMessageIdx]]
;OnRefreshAction=[!Log "Start of a #DelayDuration# ms delay"][#StartDelay[#EndMessageIdx]]
;OnRefreshAction=[#StartDelay[#EndMessageIdx]]

---Meters---

[DummyMeter]
Meter=Image
W=100
H=100
SolidColor=255,0,0,255

Result: none of the first 3 OnRefreshAction lines work as expected (i.e. delay happening between its adjacent bangs); the last 3 OnRefreshAction lines work as expected, but then they either use plain variables or don't have anything after the nested delay variable

Additional info: the delay seems to want to happen only as the last "instruction" or something

Expected behavior: I want the 1st OnRefreshAction line to behave exactly like the 4th one, as otherwise OnRefreshAction doesn't have a problem with nested variables since the end message nested variable works on its own

So, is it a bug? Can it be fixed?

[death.crafter]

So, is it a bug? Can it be fixed?

I don't know what happens deep inside but I am pretty sure it's not a bog.

I guess what is happening is when the line is read by parser first time, it doesn't find a !Delay bang in between. So it tries to execute all the [<bangs>] present simultaneously(parallel). Then the parsed variable is considered and so is the !Delay bang in the variable.

So basically,

• [!SomeBang]

• [#ActionVar]

• [!SomeBang]

run parallel.

So in a nutshell, [#Variable] is not parsed firsthand and used immediately, when the skin is read. Unlike the #Variable#.

Or may be I am wrong.

[Yincognito]

I guess what is happening is when the line is read by parser first time, it doesn't find a !Delay bang in between. So it tries to execute all the [<bangs>] present simultaneously(parallel).

So in a nutshell, [#Variable] is not parsed firsthand and used immediately, when the skin is read. Unlike the #Variable#.

The parallel execution thing is not accurate, IMHO, but [#Variable] not being parsed firsthand and used immediately could be (though I fail to understand why, since as I said, the other nested form variables, e.g. [#EndMessage[#EndMessageIdx]], do work).

I added the exact same stuff to a String measure, using RegExpSubstitute, as a workaround (see the notes below!):

Code: Select all

[Variables]
DelayDuration=3000
EndMessageIdx=1
StartDelay0=
StartDelay1=[!SetOption DummyMeter SolidColor "0,0,0,255"][!UpdateMeter DummyMeter][!Redraw][!Delay #DelayDuration#][!SetOption DummyMeter SolidColor "255,0,0,255"][!UpdateMeter DummyMeter][!Redraw]
EndMessage0=
EndMessage1=[!Log "End of a #DelayDuration# ms delay"]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255
OnRefreshAction=[!Log "Dummy message 1"][RefreshActions]
;OnRefreshAction=[!Log "Dummy message 1"][RefreshActions][!Log "Dummy message 2"]

---Measures---

[RefreshActions]
Measure=String
String=#EndMessageIdx#
RegExpSubstitute=1
Substitute="^0$":"","^1$":'[!Log "Start of a #DelayDuration# ms delay"][#StartDelay[#EndMessageIdx]][#EndMessage[#EndMessageIdx]]'
DynamicVariables=1

---Meters---

[DummyMeter]
Meter=Image
W=100
H=100
SolidColor=255,0,0,255

but I'm still waiting for an explanation from the devs as to whether this is normal or not. In my view, it is not, since, again, [#EndMessage[#EndMessageIdx]] works without issues on its own (so it's not a nested variables at refresh problem) ... AND the commented line in this last sample code does NOT work (despite the uncommented line working) - i.e. "Dummy message 2" is shown before the "End of a 3000 ms delay" log message (by the way, the workaround in my actual code works because [RefreshActions] is the last content in the OnRefreshAction):

Log.jpg

I might be wrong here, but IMHO this is either a bug or some intentional behavior not documented in the manual.

I don't know what happens deep inside but I am pretty sure it's not a bog.

Of course it's not a bog, because it's a bug. A big fat buggy bug.
By the way, what is a bog?!

[death.crafter]

The parallel execution thing is not accurate, IMHO, but [#Variable] not being parsed firsthand and used immediately could be (though I fail to understand why, since as I said, the other nested form variables, e.g. [#EndMessage[#EndMessageIdx]], do work).

I might be wrong here, but IMHO this is either a bug or some intentional behavior not documented in the manual.

No you got me wrong.

• They need some kind of separations to separate different bangs. Here it is the square brackets ([]). So each string inside a [] pair is a bang.

• So since bangs are executed simultaneously, it tries to execute every [<string>] simultaneously. Including [#Variable].

• Then before the bangs are executed they are parsed to replace the variables and measures. There the [#Variable] becomes a bang. So in a bang that is [!Bang1][#VarBang][!Bang2], [!Bang1], [!Bang2] and [#VarBang] are executed simultaneously.

• But when they encounter a [!Delay ms] in a bang line, they wait for the specified time before parsing and executing the next bangs.

• So when you use nested variables, the parser doesn't encounter a [!Delay ms] when the line is read. So it starts parsing each [<string>] and executes them.
  Then taking the above example, [!Bang1] is parsed and executed, after parsing and replacement of variables and measures(if any) are done.
  Same thing happens to the [!Bang2] and [#VarBang] at the same time since there were no [!Delay ms] in the line.

• But when using [!Bang1]#VarBang#[!Bang2] the #VarBang# is replaced by the string assigned to VarBang immediately. So if there is a [!Delay ms] in #VarBang#, it is considered to be a part of the bang line

Well it's a probability. Let's wait for the devs.

Of course it's not a bog, because it's a bug. A big fat buggy bug.
By the way, what is a bog?!

I noticed it right away after typing but thought let's just let it stay there.

[Yincognito]

No you got me wrong.

• They need some kind of separations to separate different bangs. Here it is the square brackets ([]). So each string inside a [] pair is a bang.

• So since bangs are executed simultaneously, it tries to execute every [<string>] simultaneously. Including [#Variable].

• Then before the bangs are executed they are parsed to replace the variables and measures. There the [#Variable] becomes a bang. So in a bang that is [!Bang1][#VarBang][!Bang2], [!Bang1], [!Bang2] and [#VarBang] are executed simultaneously.

• But when they encounter a [!Delay ms] in a bang line, they wait for the specified time before parsing and executing the next bangs.

• So when you use nested variables, the parser doesn't encounter a [!Delay ms] when the line is read. So it starts parsing each [<string>] and executes them.
  Then taking the above example, [!Bang1] is parsed and executed, after parsing and replacement of variables and measures(if any) are done.
  Same thing happens to the [!Bang2] and [#VarBang] at the same time since there were no [!Delay ms] in the line.

• But when using [!Bang1]#VarBang#[!Bang2] the #VarBang# is replaced by the string assigned to VarBang immediately. So if there is a [!Delay ms] in #VarBang#, it is considered to be a part of the bang line

First, my interpretation of "parallel execution" in Rainmeter is this, from the manual:

While you can "stack up" actions in a single action option:

IfTrueAction=[!SetOption SomeMeter X "5"][!SetOption SomeMeter X "10"]

Rainmeter will run both of the actions in the same Update cycle, before it updates the meters and redraws the skin, and so in effect they both visibly happen "at once". The meter won't visibly move to "5" and then "10", but will just jump straight to "10".

I'm not sure running multiple actions in a "stack" in the same Update cycle qualifies as parallel execution. They still follow one after the other, i.e. not happening at the same exact time. It's like dropping a bag of nuts on the ground: they'll appear to hit the ground all at once, but each nut will follow the preceding one (not sure if pun is intended or not here, LOL).

Secondly, parsing and replacement of variables and measures (if any) should happen for the delay related variable (irrespective if it's nested or not) as well, thus "the parser doesn't encounter a [!Delay ms]" statement seems strange, to say the least.

Thirdly, if my understanding of this is right, the delay bang does not "wait for the specified time before parsing and executing the next bangs", it has nothing to do with parsing stuff, only with the execution part.

That being said, I agree with you that using nested variables in bangs might mean that the parsing of the bangs within the nested variable happen at a later time, i.e. at the moment of execution, aka right after refresh (and not when the skin is read by the parser). That could explain the unwanted effect. It's just that I felt some of the things you said were incorrect above.

[death.crafter]

Thirdly, if my understanding of this is right, the delay bang does not "wait for the specified time before parsing and executing the next bangs", it has nothing to do with parsing stuff, only with the execution part.

Well the parsing concept is based on my nested variable escaping thread. Well yeah may be I am wrong but here is what I understand:

• When I want to use a variable bang like this: Bang=[!WriteKeyValue SomeSection SomeKey "[#**SomeVar**]"], where my intention is to write the value as [#SomeVar].

• Theoretically this should work. [#**SomeVar**] would be [#*SomeVar*] after the first parsing of the variable bang. So the bang would be:
  [!WriteKeyValue SomeSection SomeKey "[#*SomeVar*]"]
  and after execution the value written will be SomeKey=[#SomeVar].

• But this is incorrect. The correct bang would be:
  Bang=[!WriteKeyValue SomeSection SomeKey "[#***SomeVar***]"], because:
  
  • When the bang is executed by let say LeftMouseUpAction=[#Bang], first the whole line is parsed, making
    [#***SomeVar***] -> [#**SomeVar**].
  • Then the bang between [] is parsed, making
    [#**SomeVar**] -> [#*SomeVar*].
  • Then action is executed.

But this was not my point. My point was, the bangs are separated right when first time the whole bang line is parsed. I don't know If I am correct but each bang(a string present inside []) present in a line is parsed once before execution, according to my observation.(wow it rhymes). So !Delay ms is parsed too ofc. Then bangs are executed.

As you said nuts falling from a bag. Now after the first parsing, from my example before, [!Bang1] becomes one nut, [#VarBang] becomes one nut, and [!Bang2] becomes one nut. Then they fall.

So yes the bangs are stalked but they are executed one after another. It was my mistake for stating them as simultaneously.

But irrespective of that, [!Bang1] touches the ground, next [!VarBang] and next [!Bang2].

Now what's inside of [#VarBang] doesn't matter since the first parser takes it as a bang. So right after starting to execute it, it will execute [!Bang2].

So even if [#VarBang] contains delays, it's path is different. Like I said "parallel". Not simultaneous though, like you pointed out. Cuz the next bangs wouldn't wait for the previous bangs' completion.

[Yincognito]

Well yeah may be I am wrong but here is what I understand...

Yeah, I understand what you mean - it's more or less equivalent with what I said earlier that the parsing to get to the !Delay is itself delayed due to various circumstances like belonging to a bang, being a nested variable, and all that. Let me simplify even more my sample code, this time without any !Delay bang, since I'm curious if this happens on my updated sample.

And here we go:

Now what's inside of [#VarBang] doesn't matter since the first parser takes it as a bang. So right after starting to execute it, it will execute [!Bang2].

Check out this:

Code: Select all

[Variables]
StartMessageIdx=1
MiddleMessageIdx=1
EndMessageIdx=1
StartMessage1=[!Log "1"]
MiddleMessage1=[!Log "2"]
EndMessage1=[!Log "3"]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255
OnRefreshAction=[#StartMessage[#StartMessageIdx]][#MiddleMessage[#MiddleMessageIdx]][#EndMessage[#EndMessageIdx]]
;OnRefreshAction=#StartMessage1#[#MiddleMessage[#MiddleMessageIdx]]#EndMessage1#
;OnRefreshAction=#StartMessage1#[#MiddleMessage[#MiddleMessageIdx]][#EndMessage[#EndMessageIdx]]
;OnRefreshAction=[!Log "1"][#MiddleMessage[#MiddleMessageIdx]][#EndMessage[#EndMessageIdx]]
;OnRefreshAction=[#StartMessage[#StartMessageIdx]][#MiddleMessage[#MiddleMessageIdx]][!Log "3"]
;OnRefreshAction=[!Log "1"][#MiddleMessage[#MiddleMessageIdx]][!Log "3"]

---Meters---

[DummyMeter]
Meter=Image
W=100
H=100
SolidColor=255,0,0,255

All the (commented or not) OnRefreshAction lines produce the same result: 1, 2 and 3 are written to the log, in this ascending order, irrespective if the bang is contained within a nested variable or not (you can try other variations of it, of course). This doesn't match your statements that "it doesn't matter what's there" because it's not completely parsed yet, unless I misunderstood the whole thing you were trying to convey.

Log 1.jpg

Also, even if you were right, the latest simplified sample doesn't produce unwanted effects, while the one with !Delay-s instead of !Log-s does. For me, that's the definition of a bug: something that should work (since all these belong to the same category, i.e. bangs within nested variables, in the OnRefreshAction), but don't - despite the fact that everything else from that category does work.

P.S. Now try inserting a [!Delay 3000] at the start of one of those message variables (except the end one, obviously), and prepare yourself to see things go haywire...

Log 2.jpg

P.S.S. This happens even in a regular LeftMouseUpAction=[#StartMessage[#StartMessageIdx]][#MiddleMessage[#MiddleMessageIdx]][#EndMessage[#EndMessageIdx]] added to the meter, by the way (where, let's say, StartMessage1=[!Delay 3000][!Log "1"]), so it has nothing to do with the [Rainmeter] section not supporting dynamic variables (though the nested ones are a bit of a super-dynamic ones, since they work in non-dynamic sections as well).

[death.crafter]

I don't see any reason why not.

Nuts:

• [#StartMessage[#StartMessageIdx]]

• [#MiddleMessage[#MiddleMessageIdx]]

• [#EndMessage][#EndMessageIdx]

Well nuts fall in order

But if you had MiddleMessage1=[!Log "1.5"][!Delay 3000][!Log "2.5"], log would have printed,

Log:
0.00 - 1
0.16 - 1.5
0.32 - 3
3.16 - 2.5

[Yincognito]

But if you had MiddleMessage1=[!Log "1.5"][!Delay 3000][!Log "2.5"], log would have printed,

Log:
0.00 - 1
0.16 - 1.5
0.32 - 3
3.16 - 2.5

It should have printed this though:

Log:
0.00 - 1
0.16 - 1.5
3.16 - 2.5
3.32 - 3
because the 3 seconds delay would postpone BOTH the [!Log "2.5"] AND the [!Log "3"] messages for 3 seconds, since they all belong to the same option (MiddleMessage1 is not a separate option), now isn't it? Come on, think about it.

[Yincognito]

Plain example based on your log reply:

Code: Select all

[Variables]
StartMessageIdx=1
MiddleMessageIdx=1
EndMessageIdx=1
StartMessage1=[!Log "1"]
MiddleMessage1=[!Log "1.5"][!Delay 3000][!Log "2.5"]
EndMessage1=[!Log "3"]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255
OnRefreshAction=[#StartMessage[#StartMessageIdx]][#MiddleMessage[#MiddleMessageIdx]][#EndMessage[#EndMessageIdx]]

---Meters---

[DummyMeter]
Meter=Image
W=100
H=100
SolidColor=255,0,0,255
LeftMouseUpAction=[!Log "1"][!Log "1.5"][!Delay 3000][!Log "2.5"][!Log "3"]

The OnRefreshAction gets things wrong, while the LeftMouseUpAction gets things right.