GitHub | DeviantArt | Tumblr
This is the song that never ends. It just goes on and on my friends. Some people started singing it not knowing what it was, and they'll continue singing it forever just because . . .
@Faradey: Thats not what I want, that would show the temperature as before, but only if it is in the given range... This doesnt scale the value.
@smurfier: Good idea! That works
But I set Percentual=1 instead of Autoscale=1 for the histogram, then its correct.
There is just one small problem:
The histogram always shows the previous value, not the current value.
For example, if the temperature is at 40° for some time, then goes to 50°, the value is directly shown in the value meter, but the histogram shows it one period later. You could call this a rainmeter bug I think... Or is this by design?
This is because it takes one update period for the calc measure to pull the value of the measure. What you can do is pass the value of measureCPUTemp through a calc measure and use that for your string meter so they would both be one update behind.
GitHub | DeviantArt | Tumblr
This is the song that never ends. It just goes on and on my friends. Some people started singing it not knowing what it was, and they'll continue singing it forever just because . . .
Yes, that would synchronize them. Better would be, if the calc measure wouldnt cause a delay. This would be possible, so the developers could take this as a suggestion
scavenger wrote:Yes, that would synchronize them. Better would be, if the calc measure wouldnt cause a delay. This would be possible, so the developers could take this as a suggestion
Actually, no, this would not be possible due to the nature of how Rainmeter works.
It would be possible. Of course, the way, how rainmeter works, would have to be changed.
The calculation of the measures could be done iterative, first the normal measures, in a second step the calc measures, to have the current values. You would also have to consider dependencies between calc measures, so there could be some thinking necessary...
scavenger wrote:It would be possible. Of course, the way, how rainmeter works, would have to be changed.
The calculation of the measures could be done iterative, first the normal measures, in a second step the calc measures, to have the current values. You would also have to consider dependencies between calc measures, so there could be some thinking necessary...
Well, point taken that is is a computer program, so just about anything is "possible", but there a lot that revolves around the processing flow of Rainmeter as is, and I would resist a "fix it" approach that would by its nature be a kludge and have the potential for all kinds of unintended consequences. If a complete re-design of Rainmeter ever happens, and that is not out of the realm of possibility either, this matter should be kept in mind for sure. As it is, I see it as the most minor of irritants, and not a serious problem.
