Question on config portability

[desgen]

I'm having trouble finding out how the settings work in terms of portability.

A lot of the more useful settings are added via registry, not by the .ini file.

For example, if I wanted to customize settings to get alert notifications on other computers other than mine, I'd have to import the settings via registry. Exporting from what's generated for my computer:

(just an example to see how it works)

[HKEY_CURRENT_USER\Software\HWiNFO64\Sensors\F0018690_1\Volt4]
"Row"=dword:00000049
"List"=dword:00000000
"AlertEnabled"=dword:00000001
"AlertBelowValue"=""
"AlertAboveValue"="10.000000"
"AlertDispWindow"=dword:00000001
"AlertChangeItemColor"=dword:00000000
"AlertPlaySound"=""
"AlertRunProg"=""
"AlertRunProgArgs"=""
"AlertDistance"=dword:00000005
"AlertSamples"=dword:00000001

Does this mean it'll likely only work for my computer? Since the +12v sensor could be in a different row number.

What would this mean?

F0018690_1\Volt4

Could this hypothetically be something like:

F0018645_1\Volt5

On another PC? Or is F0018690_1\Volt4 universally recognized as the +12v sensor? If not, that means if I export my settings, another PC won't recognize it. Is there any particular reason most settings are handled and saved in the registry?

Same with the auto logging hotkey, why is this in the registry instead of the .ini file? Just wondering why custom settings are split between two ways of configuration.

I mean, it works for me, but the concern is will it work for others?

(If you're wondering this is for a not for profit project of mine, I don't intend to break rules or modify and redistribute what I am not allowed to)

Edit: I also noticed this:

"Row"=dword:00000049

I hope that doesn't mean if it's the sensor on the 49th row in the HWiNFO sensors window, because the sensor I want to configure alerts for could be the 42nd row, for example on another PC.

 

[Martin]

The reason for splitting the settings is what you already found out - machine-specific settings are kept in the registry. This is because each system has a different set of sensors and their addresses, so it's not possible to port such settings between different machines. Best way is to configure these settings via user interface in HWiNFO.

 

[desgen]

The reason for splitting the settings is what you already found out - machine-specific settings are kept in the registry. This is because each system has a different set of sensors and their addresses, so it's not possible to port such settings between different machines. Best way is to configure these settings via user interface in HWiNFO.

Ah, I see.

Any chance in the future of configuring for generic sensor labels via .ini file? I mean, technically it'd be possible right?

For hypothetical example in the .ini:

+12v Rail:

12vAlertEnabled=1
12vAlertBelowValue=
12vAlertAboveValue=1.
12vAlertDispWindow=1
12vAlertChangeItemColor=
12vAlertPlaySound=
12vAlertRunProg=
12vAlertRunProgArgs=
12vAlertDistance=

Example for any HDD:

SMARTAlertEnabled=1
SMARTAlertBelowValue=
SMARTAlertAboveValue=1.
SMARTAlertDispWindow=1
SMARTAlertChangeItemColor=
SMARTAlertPlaySound=
SMARTAlertRunProg=
SMARTAlertRunProgArgs=
SMARTAlertDistance=

Any CPU vcore voltage:

CPUvAlertEnabled=1
CPUvAlertBelowValue=
CPUvAlertAboveValue=1.
CPUvAlertDispWindow=1
CPUvAlertChangeItemColor=
CPUvAlertPlaySound=
CPUvAlertRunProg=
CPUvAlertRunProgArgs=
CPUvAlertDistance=

Any CPU temp:

CPUTempAlertEnabled=1
CPUTempAlertBelowValue=
CPUTempAlertAboveValue=1.
CPUTempAlertDispWindow=1
CPUTempAlertChangeItemColor=
CPUTempAlertPlaySound=
CPUTempAlertRunProg=
CPUTempAlertRunProgArgs=
CPUTempAlertDistance=

Any CPU/CPU core frequency:

CPUFreqAlertEnabled=1
CPUFreqAlertBelowValue=
CPUFreqAlertAboveValue=1.
CPUFreqAlertDispWindow=1
CPUFreqAlertChangeItemColor=
CPUFreqAlertPlaySound=
CPUFreqAlertRunProg=
CPUFreqAlertRunProgArgs=
CPUFreqAlertDistance=

Example for logging on startup

AutoLoggingAtLaunch=1

So on and so forth....

I think adding this functionality would be amazing thanks for your work on this application by the way.

 

[Martin]

Such a feature might be added some day, but not in the near future. Currently there's a lot of other higher priority tasks in the queue.
It also requires certain prerequisites to be implemented (generalized sensor classification), on which I have already started to work, but it's a quite large effort to implement even those.