This will never work. If it's 9 PM, for example, i.e. 2100, then 2100>2000 ... but 2100 is NOT less than 0600. You'd better base this on the number of seconds in the day that have passed instead (or modify the IfCondition to ((MeasureTime > 2000 ) && (MeasureTime < 2359)) || ((MeasureTime > 0000 ) && (MeasureTime < 0600))). Oh, and also, set your update to 1000 ms. No point updating this one tenth of a second, like you do now through Update=100, because Rainmeter can't measure time under the second anyway.
By the way, && means logical AND, while || means logical OR above.
P.S. Optionally, you might want to cover the equality with the bounds case, saying for example: ((MeasureTime >= 2000 ) && (MeasureTime < 2359)) || ((MeasureTime >= 0000 ) && (MeasureTime < 0600))
That goes for the other if conditions as well.
Last edited by Yincognito on November 1st, 2020, 5:44 pm, edited 2 times in total.
EDIT: Well, Yincognito and jsmorley beat me, however take into account the rest of my recommendations, except the first one (which is exactly what they also said).
zaxnite wrote: ↑November 1st, 2020, 4:56 pm
still shows only the first one
Note a few things related to the code:
There is no valid conditon in case the time is either 6:00, 14:30, 19:59 or 20:00. I'd include some equalities beside the inequalities inot the IfConditions.
IfCondition3 is never met. While the time can be between 6:00 and 14:30 or between 14:30 and 20:00, it can't be greater then 20:00 AND smaller then 6:00. So the && operator of the IfCondition3 option should be ||, which leads IfCondition3 to be true between 20:00 and 6:00.
[MeasureEqual] is not needed. You can add the IfConditions directly to the [MeasureTime] measure. I added them so and rewrote the MeasureTime measure name into the IfCondition as #CURRENTSECTION#. If we're using the conditions on the [MeasureTime] measure, #CURRENTSECTION# is equal to MeasureTime and can beused into the Ifconditions this way.
Doesn't worth to update the skin ten times per second. Replace the Update=100 option of the [Rainmeter] section with the default Update=1000.
I'd add a # character into the Format option of the [MeasureTime], to the hour, to avoid the leading zeros. I modified the IfCondition options accordingly.
With the above modification the code look like this (and it does work for me):
There is no valid conditon in case the time is either 6:00, 14:30, 19:59 or 20:00. I'd include some equalities beside the inequalities inot the IfConditions.
IfCondition3 is never met. While the time can be between 6:00 and 14:30 or between 14:30 and 20:00, it can't be greater then 20:00 AND smaller then 6:00. So the && operator of the IfCondition3 option should be ||, which leads IfCondition3 to be true between 20:00 and 6:00.
[MeasureEqual] is not needed. You can add the IfConditions directly to the [MeasureTime] measure. I added them so and rewrote the MeasureTime measure name into the IfCondition as #CURRENTSECTION#. If we're using the conditions on the [MeasureTime] measure, #CURRENTSECTION# is equal to MeasureTime and can beused into the Ifconditions this way.
Doesn't worth to update the skin ten times per second. Replace the Update=100 option of the [Rainmeter] section with the default Update=1000.
I'd add a # character into the Format option of the [MeasureTime], to the hour, to avoid the leading zeros. I modified the IfCondition options accordingly.
With the above modification the code look like this (and it does work for me):
I believe this to be the correct answer. While I think using #CURRENTSECTION# might be a bit pointless, and only adds a tiny, tiny amount of extra work to resolve the variable, the rest of it is how I would go. While it's not important, I agree in principle with not allowing the leading zeros on the hour, as technically speaking, there is no such number as 0600. Rainmeter will ignore the leading zero when used in math, but it's cleaner this way...
And refreshing the skin. It will change from 1 to 2 to 3 properly. That assumes that you actually have all three images where you think you do.
Actually, it won't, from an expected behavior point of view - and I think that was the problem. I just tested (got past 20:00 locally just now), and it didn't change the wallpaper immediately ... because it waited for a whole minute to do it. I think this might have been the issue in the first place, that's why I suggested approaching this based on the number of seconds in the day that passed.
That being said, it's not a tragedy, just a bit of delay, according to the code.