I am trying to create a skin in which the CPU bar moves smoothly, but I am having trouble. I think it is in my using of #CPU# in my calc function, but I'm not sure. Please help me by letting me know what I am doing incorrectly.
Aside from anything else, "Update=" is a setting which can only be set once, in the [Rainmeter] section of the skin. You can never change it, and you can never have a skin which does anything "faster" than what is set in Update= in [Rainmeter]. UpdateDivider / UpdateRate can be used to make a particular part of a skin (a given measure or meter) run "slower" than what is set in Update=, but never faster.
Thanks for that. I changed that but your suggestion doesn't address the overall issue I am having. Is it even possible to do computations on something being measured?
Yes you can, but your syntax needed some work. You can't reference a "variable" without putting it inside pound signs, and you can't use just .01 in a formula. It needs to be 0.01 or you get a syntax error.
jsmorley wrote:Yes you can, but your syntax needed some work. You can't reference a "variable" without putting it inside pound signs, and you can't use just .01 in a formula. It needs to be 0.01 or you get a syntax error.
I've implemented what you've said, but now I'm having the problem that the code is not storing the new value of NUMBER. I've tried setting the MeasureName = CPU_SMOOTH and MeasureName = CPU_SMOOTH_SET, but neither of them are storing the new value...the meter is always centered around 30% and goes either to 31% or 29%. Here's my updated code:
1) If you are going to use the value of NUMBER in a dynamic way (which you are) you want to be sure your meter using it has DynamicVariables=1 set on it, or it will never see the altered value set by !RainmeterSetVariable. I can't tell if "..." includes this, but it is required.
2) An IfAction, like IfAboveValue, works in the following way. It will fire the action assigned to IfAboveAction when the condition in IfAboveValue becomes "true", but will not fire it again until it becomes "false" and then "true" again. This is to keep IfActions from just running amok and continuously firing actions when for instance the IfAboveValue is "1" and the detected value just keeps rising to 2, 3, 4 etc. If has to go "below" the IfAboveValue setting, then back to "above" (false / true) to again fire the action. I am not sure from your snippets if this is going to be an issue for your code, but keep it in mind.
jsmorley wrote:
2) An IfAction, like IfAboveValue, works in the following way. It will fire the action assigned to IfAboveAction when the condition in IfAboveValue becomes "true", but will not fire it again until it becomes "false" and then "true" again. This is to keep IfActions from just running amok and continuously firing actions when for instance the IfAboveValue is "1" and the detected value just keeps rising to 2, 3, 4 etc. If has to go "below" the IfAboveValue setting, then back to "above" (false / true) to again fire the action..
Ahh! That is my problem! How do I make it so that it keeps firing until it becomes false?
Ive tried using Counter, as shown below, but that isn't working
dberm22 wrote:
Ahh! That is my problem! How do I make it so that it keeps firing until it becomes false?
Not an easy thing to do with IfActions. They are hard wired to work the way they do. You might want to explore a different approach, where instead of setting a variable on IfAboveAction, you !RainmeterEnableMeasure and !RainmeterDisableMeasure one or more measures (Calc measures perhaps) that then contain the value you want to use in your meter later.
If you "enable" a measure using !RainmeterEnableMeasure when IfAboveAction is true, it will keep updating. Then you "disable" it using an IfBelowAction on the same measure with the IfAboveAction. That way the measure will be enabled until turned off again by the IfBelowAction.
The only downside to this is that you need to be aware that every time you "kite / hand off" a value through a calc measure in order to "carry it along" like this, (or to do math on a value or convert a string to a number, some other reasons to do this) you get one "Update=" behind each time. So for a meter that directly gets a value that has been measured by something like Measure=CPU will display the "current" value, if you pass the value through one or two or three calc measures for whatever reason, each calc measure will in effect delay what is being shown by the meter by one Update each. Just something to keep in mind.
That make sense, but in my case, a .3 second delay is not a big deal. I am using counter to keep the thing firing, but I feel as if the CPU isn't being measured very often. The bar keeps jumping around (randomly?) but is increasing slightly over time. Not sure why this is. I have attached the skin in case you wanted to go above and beyond with helping me. It is a modification of this guy's work.
