I actually have some heartburn with this change.
While having the error codes available when you are debugging a skin is a good thing, in practice not being able to turn this off when you are done with the skin causes some real cosmetic ugliness, and some errors in the log that shouldn't be there.
Let me explain what I mean.
When you restart your computer, or sign-out / sign-in to to Windows, the following happens:
1) Windows starts
2) Rainmeter starts
3) Rainmeter loads the skin(s)
4) HWiNFO starts
5) HWiNFO scans the hardware sensors
6) The Rainmeter HWiNFO plugin sees the sensor values
The problem is that no matter what order 2-4 happens in, the certain thing is that 5) HWiNFO scans the hardware sensors, is going to take some time, some number of seconds. While HWiNFO is scanning the sensors, your skin is going to be sitting there with error values in the meters. The real problem cosmetically is that something like a hardware temperature, that was likely designed around 2 or at most 3 characters, is now 5 characters (-9000 for example) and doesn't fit, and at the same time, you are getting a ton of errors in the log that are not really errors, but just a question of timing. This is going to happen every time you start Windows.
I'd really like to see a way to turn off this error trapping. Perhaps a new option on the plugin measures. It would be nice to have while building and testing the skin, but I don't care for it as an ongoing factor.
What I did to work around this for now is:
Code: Select all
So I have this first plugin measure, that I call [MeasureHWiNFOAwake], that simply tests one of the temperature sensors I'm also using later in the skin, but this measure isn't used in a meter itself. If it returns a value above zero then I know all is well, and I can enable the rest of the measures, they will return "0" while disabled, which is cosmetically more pleasing while the skin is "waiting" than "-9000" is. This also stops the bogus errors in the log.
I guess my point is that the time that the skin is waiting for HWiNFO to finish scanning your hardware is not an "error". It's a perfectly reasonable issue of timing, that there needs to be some graceful way to handle. I'm open to different approaches...
Edit: ARGH! It's even worse than that. For some reason the plugin is not obeying "Disabled=1" on the plugin measures, and so while the measures return "0" to the meters ok, the log is still full of "errors" that don't make sense at all.