The way it works is that when the skin is loaded or refreshed, the plugin is sent the Reload() function. This is going to be the place where you do things you generally need to only happen once. Reading measure parameters is one good example. What else you do in this function will vary depending on the plugin, but it's certainly a good place to do CPU intensive things that only need to happen one time.Well, this sounds like a Rainmeter issue to me. Shouldn't Disabled not call anything, and Paused does not call Update? Right now they sound the same.
As we discussed before the change, I was going to log to Rainmeter only once at Reload and output the values in the skin at Update. Otherwise there is not a way for me to only write to the log once unless I start tracking that internally with the measure. This is why I asked if there are standard measure parameters that I should be honoring. If you are going to call the Reload function anyways, then maybe I need to store the disabled state and check it when Reload fires so I can abort. I matched the logging frequency to the function frequency.......seemed logical, no?
Note that while normally Reload() is only fired once when the skin is loaded or refreshed, setting DynamicVariables=1 on the measure in the skin will cause Reload() to be fired on every measure update, allowing a user to have dynamically changing parameters on the measure for instance.
Update() happens on every update of the measure in the skin. This is where you take whatever repetitive actions the plugin is designed for, like reading senor values and returning the values.
Disabled and Paused are in fact much the same. They both prevent the skin from updating the measure, and so no Update() call is made to the plugin. The difference between the two is that Disabled sets the measure value to "0" and Paused simply retains whatever the previous value was. However, neither prevents the Reload() function from being called when the skin is loaded or refreshed.
So it's not that the plugin needs to know or react to the "disabled" state of the measure, no need for that. The disabled or paused state of the measure simply determines if the Update() function is called in the plugin or not during the skin update cycle.
I'm not suggesting you change your plugin, I just don't think this minor issue warrants it, but in the case of HWiNFO, having it actually read and use the shared memory in Reload() and producing errors if it can't is absolutely guaranteed to generate errors on every system restart. There is no reasonable way to be certain that HWiNFO starts before Rainmeter, and even if you could / did, the time it takes for HWiNFO to scan for the sensors will mean that you would have to delay the start of Rainmeter for some unknown and variable number of seconds, somewhere between 5-30. Nobody is going to do that to support one skin.
Make no mistake though, in one sense the issue here really isn't Reload() vs. Update(), and I only explained those above mostly for information's sake. There will be multiple Update() calls made as the skin loops through the normal update cycle before HWiNFO can possibly finish scanning the hardware, so even if Reload() is designed not to produce errors, maybe not to interact with HWiNFO at all, errors are still going to be produced when the system is first started. However, the difference is that I have some control over Update() with Disabled or Paused, but no control at all over Reload(). That IS going to be fired.I could in theory introduce a "timer" in the skin that waits 20 seconds before enabling plugin measures when the system is first started.
All that aside, my thinking with the proposed new parameters concerning logging is that I might set up one plugin measure, who's only job it is is to get one single senor value, and test for "-9xxxx". If the value is not "-9xxxx" then I know all is well, and I can "enable" all the other "real" measures that are getting the senors values. If it is "-9xxxx", then I just leave them all disabled. I set the "no error logging" parameter on that first measure, so it doesn't get the error produced by the "timing" issue when the system is restarted.
I really don't want to stay on 3.0, as I don't want to be stuck depending on it's functionality as the plugin potentially moves forward over time to 3.2, 3.3 or whatever other changes you might make in the future based on some clever ideas you have, or due to changes in HWiNFO itself. However, due to this really unsolvable "timing" issue, I would ask that now and going forward thee is more control given over what "logging" is done. The fact that errors return values of "-9xxxx" is fine, and in fact vastly preferable as it allows for definitive testing for actual errors. It is just trivial to deal with any cosmetic issues caused by "-9xxxx". It's only the errors in the log that I can't be the master of today.