Hi,

I am writing and reading a value to the registry using wwApi.WriteRegistryString and wwApi.ReadRegistryString.

When loApi.writeRegistryString(HKEY_LOCAL_MACHINE,'Software\Sosa y Cia., S.A.','ccc','CCC',.t.) is issued the command returns .T. and the value is created or modified as expected.

But when loApi.ReadRegistryString(HKEY_LOCAL_MACHINE,'Software\Sosa y Cia., S.A.','ccc') is issued the command RegOpenKey(tnHKey,tcSubKey,@lnRegHandle) in ReadRegistryString returns 2 and the process is aborted returning NULL.

What may be happening?

TIA,

Alex

Take a look here perhaps?

https://stackoverflow.com/questions/252297/why-is-regopenkeyex-returning-error-code-2-on-vista-64bit

Certain keys get marshalled into the 32 bit registry hive when using a 32 bit app.

You really shouldn't write your company specific keys into HKEY_LOCAL_MACHINE. Write them HKEY_CURRENT_USER.

Besides the 32/64 bit confusion there's also permissions issues as you need to be an Admin to write to HKEY_LOCAL_MACHINE.

+++ Rick ---

Thank you very much for the response Rick.

I had noticed the redirection to Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Sosa y Cia., S.A. and thought reading from LocalMachine as not the administrator would pick it up the value from the same place.

Thanks,

Alex

No application specific settings should go into HEKY_LOCAL_MACHINE. It's not the right place - use HKEY_CURRENT_USER\Software\Company\Product to write your keys and you should get the expected behavior.

That's also where applications will expect to look for keys.

FWIW - if you can help it don't use the registry for configuration. It's much nicer to use a configuration file as JSON or XML as that's more portable. You can read a whole bunch of values on startup then track a configuration object around.

These days I only use the registry for things like Software Registration keys or other system specific settings.

+++ Rick ---

Thanks. In fact, this case was for software registration, which is why I was trying to tie the machine itself rather than the user. But I can live with CURRENT_USER, which is good enough and easier than asking the user to sign in as administrator.

Alex