The [!Delay "60000"] bang sets the length of the pause (in milliseconds). That's why I've set there 60000. You can easily modify it, if you want another length of the pause.
The IfConditions set when the measure is paused / finished. When finished, it is disabled. You can re-enable it through a click to some meter and in such case, the animation starts again, from the beginning (adding a LeftMouseUpAction=[!EnableMeasure "ImageNumberCalc"] option to the appropriate meter, which starts over again the animation).
Instead of a such low Update value (which isn't a good idea, due to the increasing resource - CPU - usage), I'd use the ActionTimer plugin. It should have to be run ONLY while the animation is running.
ColorCode wrote:What if replace "pause time" (60 seconds) with a solid color.
Well, I didn't understand this! You would like to replace the the whole skin with a black solid color, while the measure is paused?
ColorCode wrote:But, since the animation is a separate animation.ini which runs every 20 minutes for 60 seconds do I need that?
Exactly this is why you need it, in my opinion. There is no good reason to continuously run a skin with a such low Update value for 20 seconds, when the animation is hidden.
I rewrote your code, to use the ActionTimer plugin. In such cases it is an extremely useful plugin. The [AnimationStartBG] Image meter now works not with a measure, but with a variable.
Please test this code and let me know if it does work for you:
The Update value of this code is -1. This means the skin isn't updated at all (just in the very first moment, when it is refreshed / loaded). This way the skin is much less "hungry", regarding the CPU usage.
Obviously the WaitTime variable (set up in the [Variables] section) is the period while the animation is paused, when it is (expressed in seconds). Change it if you need to.
The Step and Wait variables are used by the code, you don't have to take care of them.
The !Execute bang (which you've used in the OnRefreshAction option of the [Rainmeter] section) is deprecated and should have to be removed. I did it.
I load EyeCareWorkTime. It starts count down and after 10 seconds, it loads the FP-RestAnimation. It also counts down and after it reaches 0 it is unloaded but the EyeCareWorkTime starts counting down again. When it reaches 0, FP-RestAnimation is reloaded. Then everything starts all over again: FP-RestAnimation loads EyeCareWorkTime and this one loads FP-RestAnimation and so on.
And one more detail, I just saw: unlike the !ActivateConfig bang, the !DeactivateConfig doesn't need two parameters. The name of the config is completely enough.
Eg in the OnRefreshAction option ([Rainmeter] section) of the EyeCareRestTime.ini skin you have the following bang: [!DeactivateConfig "EyeCareScreenSaver" [color=#FF0000]"EyeCareScreenSaver.ini"[/color]]. The red part of this bang isn't needed. If you tell Rainmeter what config it has to close (deactivate), it knows which skin of that config is loaded and will unload that one. So the correct form of that bang would be: [!DeactivateConfig "EyeCareScreenSaver"]. I know even the first form of the bang is working, but correctly it shouldn't have to have that form.
Ok, I did copy the new measure, but the animation still isn't working perfectly: the black patch grows, the countdown starts and when it reaches 0, the patch starts to decrease, but before it would finish this decreasing, it is closed.
The solution I think would be to increase the IfAboveValue of the [AnimationOffDelay] measure of the EyeCareWorkTime.ini skin. I tried with IfAboveValue=6 and this seems to be all right.
ColorCode wrote:Despite having 9 year old laptop, It runs smoothly for me.
It ran smoothly, not this was the problem. The problem was that the animation wasn't finished, being interrupted before it got finish. As I said, replacing the IfAboveValue fixed the issue.