Some issues with !Refresh

[Yincognito]

I found the answer

Note that the counter goes to 1 and that it has een UpdateDiver=-1. That UpdateDivider doesn't let it go beyond 1. It was added as an additional safety in the original code i copied but became an obstacle (without me realising it) in my own code when i changed the counter to 5. I completely overlooked this.

I removed the UpdateDivider and then it worked.

I still don't fully understand the reason why it worked with

Code: Select all

[!CommandMeasure Update][!Redraw]

but OK. It probably forcibly updated the Measure beyond the count of 1. Presumably something like

Code: Select all

OnUpdateAction=[!CommandMeasure MeasureOnLoad2 Update]
[!Redraw]

I spend the better part of two weeks trying to figure this out

The Devil is in the details

Yeah, I wanted to talk about the UpdateDivider=-1 on the Counter function being the culprit, but I wasn't sure how the function like this works, as I never used it. I did however post a reply to you last night, which, for some reason, didn't get saved here, so I'll post the code again (without the explanation though), so you can have an alternative:

Code: Select all

[Variables]

[Rainmeter]
Update=1000

---Measures---

[MeasureCurrentNumber]
Group=SourceGroup
Measure=Calc
Formula=((MeasureCurrentNumber+1)%2)
UpdateDivider=-1
DynamicVariables=1

[MeasureLocalTime]
Group=SourceGroup
Measure=Time
FormatLocale=Local
UpdateDivider=-1
OnUpdateAction=[!WriteKeyValue Variables Number "[MeasureCurrentNumber]" "#CURRENTPATH#Test.inc"][!WriteKeyValue Variables Check "[MeasureLocalTime]" "#CURRENTPATH#Test.inc"][!EnableMeasure "MeasureWebParserReadData"][!UpdateMeasure "MeasureWebParserReadData"][!CommandMeasure MeasureWebParserReadData "Update"]

[MeasureWebParserReadData]
Disabled=1
Measure=WebParser
URL="file://#CURRENTPATH#Test.inc"
RegExp="(?siU).*\nNumber=(.*)\nCheck=(.*)\n"
CodePage=1200
UpdateRate=-1
FinishAction=[!UpdateMeasureGroup "DataGroup"][!UpdateMeter *][!Redraw]

[MeasureNumber]
Group=DataGroup
Measure=WebParser
URL=[MeasureWebParserReadData]
StringIndex=1
UpdateDivider=-1

[MeasureCheck]
Group=DataGroup
Measure=WebParser
URL=[MeasureWebParserReadData]
StringIndex=2
UpdateDivider=-1

---Meters---

[MeterAll]
Meter=STRING
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=MeasureCurrentNumber
MeasureName2=MeasureNumber
MeasureName3=MeasureLocalTime
MeasureName4=MeasureCheck
Text="Number = written %1, read %2#CRLF#L.Time = written %3, read %4"
LeftMouseUpAction=[!UpdateMeasureGroup "SourceGroup"]

[Wim]

Hi Yincognito

Thx for the code. It's interesting since it does the same thing i did in a completely different way. I also think yours is a lot better than mine. I'm going to have a good look at it. Thnx again.

[balala]

I found the answer

The code i was using was

Code: Select all

[MeasureOnLoad2]
Measure=Calc
Formula=Counter
IfEqualValue=5
IfEqualAction=[!Refresh]
UpdateDivider=-1

It didn't work. If i looked in the about screen i saw this

Counter1.PNG

I suddenly realised that the counter on MeasureOnLoad2 always stops at 1 and therefore never goes to the required value of 5, so there's no refresh.

This didn't work, because there is an UpdateDivider=-1 option, which prevents the measure to be incremented. On load of the skin (note that not on every refresh, just once, immediately after loading the skin), the value of the measure becomes 1 and it is kept so, it doesn't increments. So the measure never gets 5 to execute the refresh, this is what you have figured out.

When i used my own 'incorrect' solution

Code: Select all

[MeasureOnLoad2]
Measure=Calc
Formula=Counter
IfEqualValue=5
IfEqualAction=!Refresh #CURRENTCONFIG#
[!CommandMeasure Update][!Redraw]
UpdateDivider=-1

the counter does move to 5 and so there's a refresh.

Counter2.PNG

In this measure the [!CommandMeasure Update][!Redraw] (which is not an option, not having an equality sign) prevents the UpdateDivider=-1 option to work. To be honest I'm not sure at all why is this happening, why those two bangs into an independent line prevents the UpdateDivider option to work, but this is the situation. So this measure, although it is set not to update, it anyway updates and reaches 5 after the appropriate number of update cycles. And obviously in this moment, the !Refresh #CURRENTCONFIG# bang is executed, that's why you get the measure working correctly.

I still don't fully understand the reason why it worked with

Code: Select all

[!CommandMeasure Update][!Redraw]

but OK. It probably forcibly updated the Measure beyond the count of 1. Presumably something like

Code: Select all

OnUpdateAction=[!CommandMeasure MeasureOnLoad2 Update]

Described above. A developer would be needed here (jsmorley or Brian - or else) to explain what's going on, I don't understand either, but this is the situation.

The Devil is in the details twisted

Definitely. And always.

[Yincognito]

Hi Yincognito

Thx for the code. It's interesting since it does the same thing i did in a completely different way. I also think yours is a lot better than mine. I'm going to have a good look at it. Thnx again.

Yeah, the thing is some of the operations you do in your skin can be done using Rainmeter's own capabilities (like reading and writing from a file, getting the local time) instead of going external with RunCommand and CMD commands (those are very useful, but for other stuff). It offers a bit greater flexibility, not to mention that another refresh after the initial one in your skin feels a bit "tricky", despite the efforts you made to avoid an endless refreshing loop by disabling the relevant measures.

For me, that is the "correct" way of doing the things you want to do. Personally, I am already applying some of these methods in my skins for years without problems.

[Yincognito]

In this measure the [!CommandMeasure Update][!Redraw] (which is not an option, not having an equality sign) prevents the UpdateDivider=-1 option to work.

I think that explains it best. That's interesting though, since usually Rainmeter just ignores this kind of stuff when it happens...

[Wim]

Hi Balala

Computer code is read line by line. Rainmeter is no exception. My 'faulty' code

Code: Select all

[MeasureOnLoad2]
Measure=Calc
Formula=Counter
IfEqualValue=5
IfEqualAction=[!Refresh]
[!CommandMeasure MeasureWebParser Update][!Redraw]
UpdateDivider=-1

will be read from top to bottom. It means that

Code: Select all

[!CommandMeasure MeasureWebParser Update][!Redraw]

is read and executed first before Rainmeter reads

Code: Select all

UpdateDivider=-1

and will therefore increment the counter by one regardless of the UpdateDivider setting.

In the bang is no config being specified (it's optional anyway) and that means that it is applied to all measures. It's visible in this screenshot

Counter2.PNG

I set MeasureOnLoad1 to a value of 1 and MeasureOnLoad2 to 5. You can see that the counter of MeasureOnLoad1 has been incremented to 6 as a result of that bang. When i used the code without the bang (and didn't work with regard to !Refresh) the counter on MeasureOnLoad1 incremented to 1, as it had been set.

Counter1.PNG

In my experience Rainmeter is not forgiving with regard to coding errors. I'm surprised that this even worked. That shouldn't have happened. What puzzles me even more is that there is no error message in the log, not even a syntax error, what i would have expected (and i had the log in debug mode).

Described above. A developer would be needed here (jsmorley or Brian - or else) to explain what's going on, I don't understand either, but this is the situation.

I would wholly agree with this assessment. I've actually been thinking it since i first had it running. You can see that from my original remarks. I thought it wasn't right. It actually was the reason me to post this question in the first place. I think it's a bug.

Edit: See Balala's remarks.

[balala]

That's interesting though, since usually Rainmeter just ignores this kind of stuff when it happens...

Yep, exactly. That's why I said a developer would be needed to explain what's going on.

[Wim]

Yeah, the thing is some of the operations you do in your skin can be done using Rainmeter's own capabilities (like reading and writing from a file, getting the local time) instead of going external with RunCommand and CMD commands (those are very useful, but for other stuff). It offers a bit greater flexibility, not to mention that another refresh after the initial one in your skin feels a bit "tricky", despite the efforts you made to avoid an endless refreshing loop by disabling the relevant measures.

For me, that is the "correct" way of doing the things you want to do. Personally, I am already applying some of these methods in my skins for years without problems.

I've been dealing with computers since the early 1980's and cmd.exe is the thing i'm most familiar with. I turn to RunCommand for that reason: because it's familiar. I was already thinking i should do more with Rainmeter's own possibilities and your code reminded me of that.

Thnx again for the code. It's interesting to compare it to my own and see what the alternatives are.

[balala]

It means that

Code: Select all

[!CommandMeasure MeasureWebParser Update][!Redraw]

is read and executed first before Rainmeter reads

Code: Select all

UpdateDivider=-1

No, it isn't, because [!CommandMeasure MeasureWebParser Update][!Redraw] is not a valid Rainmeter option. An option must have a name (not sure this is the right term) in front of the equality and a value, following the equality. Posting this way (without an option name) of two (or any number) of bangs doesn't get them executed.
Not mentioning that initially even the !CommandMeasure bang has been written incorrectly. You had this above: [!CommandMeasure Update]. Here are too less parameters for the !CommandMeasure bang, which requires two (or three) parameters, no way one.
But saw you've fixed this in meantime.

In the bang is no config being specified (it's optional anyway) and that means that it is applied to all measures.

Not sure which bang are you talking about here.

In my experience Rainmeter is not forgiving with regard to coding errors. I'm surprised that this even worked. That shouldn't have happened. What puzzles me even more is that there is no error message in the log, not even a syntax error, what i would have expected (and i had the log in debug mode).

But yes, it should work. And it does work according to the code. The only thing I can't explain is that those two bangs prevents the next UpdateDivider=-1 option to work. Otherwise everything is ok.

I think it's a bug.

If you think so, post a new topic into the Bugs & Feature Suggestions section, describing what have you figured out.

[Yincognito]

In the bang is no config being specified (it's optional anyway) and that means that it is applied to all measures. It's visible in this screenshot.
[...]
I would wholly agree with this assessment. I've actually been thinking it since i first had it running. You can see that from my original remarks. I thought it wasn't right. It actually was the reason me to post this question in the first place. I think it's a bug.

I slightly disagree. It's not applied to all measures, just the one where the faulty line is:

Code: Select all

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

;---------------------------------------------

[Variables]

;------------------------------------

[MeasureSomeTest]
Measure=Calc
Formula=(MeasureSomeTest+1)
IfEqualValue=1
IfEqualAction=
;[!CommandMeasure MeasureWebParser Update][!Redraw]
UpdateDivider=-1

[MeasureOtherTest]
Measure=Calc
Formula=(MeasureOtherTest+1)
UpdateDivider=-1

;------------------------------------

[MeterSomeTest]
Meter=STRING
X=5
Y=5
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=MeasureSomeTest
MeasureName2=MeasureOtherTest
Text="Some  Test = %1#CRLF#Other Test = %2"

This works fine and both measures stay at 1. If you uncomment the faulty line though, only the measure where the line is keeps going, not every other measure:

Faulty Line.jpg

So I think balala was right. I'm not entirely sure this should be reviewed by a developer though - it's not like Rainmeter is doing something wrong, it just can't parse the UpdateDivider line because of a previous non Key=Value line. But then, if a developer reviews this, I'm ok with it.

I've been dealing with computers since the early 1980's and cmd.exe is the thing i'm most familiar with. I turn to RunCommand for that reason: because it's familiar. I was already thinking i should do more with Rainmeter's own possibilities and your code reminded me of that.

Thnx again for the code. It's interesting to compare it to my own and see what the alternatives are.

It was my pleasure. I deal with computers since the early 2000's and I can fully understand turning to CMD - I lived that phase too...