I'm not entirely convinced yet that the idea of selecting ALL sensor elements to be output in HWiNFO is the very best idea. I did that, going from 40 sensors output to 256. The amount of CPU used by HWiNFO every 2 seconds (its polling rate) went from 0.4% to 1.2%. I have a fast machine and the CPU use is trivial for me but I'm not entirely sure this is a good recommendation for every end-user.
I can see the charm in it however, since it means that no matter what skins I create or use that might need "other" sensors that I didn't select initially, it won't mess up the index numbers in all my other existing skins and require them to be "fixed".
function ParseOutput(measureName)
local raw = SKIN:GetMeasure(measureName):GetStringValue()
local output = ""
-- Match over each group as a whole
local match_string = " Sensor(%d-) .- (.-)\n .- .- (.-)\n .- .- (.-)\n .- .- (.-)\n .- .- (.-)\n"
for index, sensor, label, value, value_raw, color in raw:gmatch(match_string) do
output = output
.."\n"
.."Index "..index.."\n"
.."Sensor "..sensor.."\n"
.."Label "..label.."\n"
.."Value "..value.."\n"
.."ValueRaw "..value_raw.."\n"
.."Color "..color.."\n"
end
-- Write to a file
local file = io.open(SKIN:GetVariable("CURRENTPATH").."output.txt", "w")
file:write(output)
file:close()
end
Index 0
Sensor System
Label Virtual Memory Commited
Value 18,096 MB
ValueRaw 18096
Color 400040
Index 1
Sensor System
Label Virtual Memory Available
Value 12,026 MB
ValueRaw 12026
Color 408080
Index 2
Sensor System
Label Virtual Memory Load
Value 60.0 %
ValueRaw 60.0
Color 0080c0
Index 3
Sensor System
Label Physical Memory Used
Value 9,450 MB
ValueRaw 9450
Color 8080c0
Index 4
Sensor System
Label Physical Memory Available
Value 6,848 MB
ValueRaw 6848
Color 008080
function ParseOutput(measureName)
local raw = SKIN:GetMeasure(measureName):GetStringValue()
local output = ""
-- Match over each group as a whole
local match_string = " Sensor(%d-) .- (.-)\n .- .- (.-)\n .- .- (.-)\n .- .- (.-)\n .- .- (.-)\n"
for index, sensor, label, value, value_raw, color in raw:gmatch(match_string) do
output = output
.."\n"
.."Index "..index.."\n"
.."Sensor "..sensor.."\n"
.."Label "..label.."\n"
.."Value "..value.."\n"
.."ValueRaw "..value_raw.."\n"
.."Color "..color.."\n"
end
-- Write to a file
local file = io.open(SKIN:GetVariable("CURRENTPATH").."output.txt", "w")
file:write(output)
file:close()
end
Index 0
Sensor System
Label Virtual Memory Commited
Value 18,096 MB
ValueRaw 18096
Color 400040
Index 1
Sensor System
Label Virtual Memory Available
Value 12,026 MB
ValueRaw 12026
Color 408080
Index 2
Sensor System
Label Virtual Memory Load
Value 60.0 %
ValueRaw 60.0
Color 0080c0
Index 3
Sensor System
Label Physical Memory Used
Value 9,450 MB
ValueRaw 9450
Color 8080c0
Index 4
Sensor System
Label Physical Memory Available
Value 6,848 MB
ValueRaw 6848
Color 008080
Looks really good. I'd lose the "Color" entries. Those were there for the old Windows Sidebar Gadget.
If a sensor isn't active, then HWiNFO will not output the sensor entries into the registry. If the sensor does become active, then the registry entries are created and indexes can be shifted.
For example: Fans. If you start HWiNFO and your CPU/GPU fan isn't spinning, then there is no data in the sensors panel. Once the fans start spinning, then the entries appear and all the indexes that follow the fan entry will shift/increment downward. (This is normal HWiNFO behavior, but entry IDs in the plug-in were unique and didn't shift around.)
This applies to batteries, network devices, plugging/unplugging drives, etc., anything that can appear AFTER HWiNFO is started. Once HWiNFO is running, things won't disappear from the sensors panel.
SilverAzide wrote: ↑March 16th, 2021, 10:47 pm
OK, I think I found an issue.
If a sensor isn't active, then HWiNFO will not output the sensor entries into the registry. If the sensor does become active, then the registry entries are created and indexes can be shifted.
For example: Fans. If you start HWiNFO and your CPU/GPU fan isn't spinning, then there is no data in the sensors panel. Once the fans start spinning, then the entries appear and all the indexes that follow the fan entry will shift/increment downward. (This is normal HWiNFO behavior, but entry IDs in the plug-in were unique and didn't shift around.)
This applies to batteries, network devices, plugging/unplugging drives, etc., anything that can appear AFTER HWiNFO is started. Once HWiNFO is running, things won't disappear from the sensors panel.
Thoughts?
Yike. That's a bit ugly. I have emailed Martin to see what he thinks.
Seems to me that we need to encourage folks to create the variables for the indexes after everything that will be running is running on their system. So what I'm hearing is that things might "appear" on the panel and get an index, like a USB drive and such. That can and will move all the index numbers below them. However, once things are recognized, they won't "disappear" from the panel if you disconnect them?
Just out of curiosity, I don't see how HWiNFO can be running and your CPU and / or GPU fan(s) are not?
jsmorley wrote: ↑March 16th, 2021, 11:08 pm
Well crap... I'd like to see what Martin thinks. This sounds prickly.
After pondering a bit, if Martin doesn't want to change anything, then perhaps a work-around would be a really lightweight plugin that is basically a Registry wrapper. Instead of taking an index, you'd pass it the Sensor and Label and it would look up the value. It could act like the old plugin and return a -9xxx number for a missing sensor or just zero if you don't care.
SilverAzide wrote: ↑March 16th, 2021, 11:14 pm
After pondering a bit, if Martin doesn't want to change anything, then perhaps a work-around would be a really lightweight plugin that is basically a Registry wrapper. Instead of taking an index, you'd pass it the Sensor and Label and it would look up the value. It could act like the old plugin and return a -9xxx number for a missing sensor or just zero if you don't care.
Yeah, I have a bad feeling that that might well end up being the answer. I suspect Martin is not going to want to potentially break, or to be honest even change, the prehensile-tail "gadget" functionality there.
I think I'd hold off on distributing any skins using this until we get this settled...
It might just be more complicated to do than you think. The Registry is very "hierarchical" in nature, and searching it is based on the key name, which today is the "index". Searching it based on "values" instead might be very, very slow. I think what we might have to do is to use a plugin that just gets that entire subkey of HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\VSB into memory in the plugin, and then searches just that to reconcile the SensorName / Label combination above and get the Value / ValueRaw.