$setting working on Windows registry

Author: gianni.sandigliano@unifacesolutions.com (gianni)

I am trying to use $setting to write the Windows registry (Topic=REGDATA) to adapt a connection between a Uniface application and another piece of software but I feel I am lost into the reign of 32bit into 64bit near the VirtualStore. :-) :-) :-) My Windows machine is 64bit while Uniface installed is 32bit; the other software I should interface with is 64bit because on a 64bit machine could only be installed the 64bit version. While trying to read the 64bit part of the registry with my 32bit Uniface application everything is OK. The tricky part is: I would like to change a registry key used from the 64bit application while executing the 32bit application but I only get back $procerror = -1118. I've dived into Microsoft docs and googled a lot but I did not reached a definitive answer. My gotfeel tell me "It is not possible!" but before giving up looking for other options I would like to ask to Unifacers: is this update possible? If NO, which is the issue? could it become possible: - using Uniface 64bit? - having admin rights? ...or it is simply not possible! One side question: examples into Uniface documentation (current ULibrary or UnifaceInfo online doc) about $setting usage with Topic=REGDATA sometimes uses the syntax: $setting("", "HKEY_LOCAL_MACHINE\TheFullPath\keyName", "REGDATA") = value while in other cases I've seen used square brackets, like this: $setting("", "[HKEY_LOCAL_MACHINE\TheFullPath]keyName", "REGDATA") = value Are both syntaxes correct? Thanks in advance for any input. Best Regards, Gianni

7 Comments

  1. Hi Gianni, In general it should be possible to write to the 64-bit part of the registry. The Uniface process of course needs the appropriate permission to do this. It would be interesting to know what exactly you are trying to do here. What is the name of the specific registry key/value? In case you can read the data from the registry value then you should also be able to update it. One possible reason that $setting returns the error -1118 could be when the name of a registry key (or value) includes one or more forward slashes. But this problem affects both reading and writing using $setting. For details see BUG#31289.

    gianni said One side question: examples into Uniface documentation (current ULibrary or UnifaceInfo online doc) about $setting usage with Topic=REGDATA sometimes uses the syntax: $setting("", "HKEY_LOCAL_MACHINE\TheFullPath\keyName", "REGDATA") = value while in other cases I've seen used square brackets, like this: $setting("", "[HKEY_LOCAL_MACHINE\TheFullPath]keyName", "REGDATA") = value Are both syntaxes correct?

    Yes, both syntaxes are correct. The first retrieve profile ("HKEY_LOCAL_MACHINE\TheFullPath\keyName") can refer to a registry key or value called keyName under HKEY_LOCAL_MACHINE\TheFullPath\. When the keyword REGDATA is used then the retrieve profile has to refer to a registry value. If REGKEYS is used then the retrieve profile is referring to a registry key. And the second one ("[HKEY_LOCAL_MACHINE\TheFullPath]keyName") refers to a registry value called keyName under HKEY_LOCAL_MACHINE\TheFullPath\. When using square brackets in the retrieve profile then you can only use the keywords REGDATA and REGVALUES. Using REGKEYS will cause the error -1118. Hope this helps. Best regards, Daniel Iseli Uniface Technical Support


    Author: diseli (daniel.iseli@uniface.com)
  2. Hi Gianni, For your first problem (32/64 bits) Introduced in 9.6.05 version : Added Source values of "32" and "64" to enable alternate registry access on older Windows Platform . Best regards,


    Author: Gilles (gls.tools@free.fr)
  3. More infos: I would like to change at runtime these registry key: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Print\Monitors\Multi File Port Monitor\HPPS:\FilePattern HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Print\Monitors\Multi File Port Monitor\HPPS:\OutputPath These registry keys are also available as CurrentControlSet but I've concentrated my action on ControlSet001. When reading them with: vFile = $setting("", "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\Multi File Port Monitor\HPPS:\FilePattern", "REGDATA") vPath = $setting("", "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\Multi File Port Monitor\HPPS:\OutputPath", "REGDATA") I get correct results: vFile=HPPS-%t-%Y%m%d%H%n%s.ps and vPath=C:\Users\Gianni\Documents\U97Devel\project. When trying to write them either with: $setting("", "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\Multi File Port Monitor\HPPS:\FilePattern", "REGDATA") = vFile or: $setting("64", "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\Multi File Port Monitor\HPPS:\FilePattern", "REGDATA") = vFile I always get $procerror = -1118 One more question: when I open regedit to look into registry Windows is interactively asking me to raise rights. How could I force my Uniface process to raise its rights NOT interactively? Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  4. Thanks for the additional info, Gianni. So it seems that the user does not have the required permission to write to the mentioned registry key. You need to start Uniface as Administrator and then it should be possible to update the values in the registry. This is not something you can do from inside Uniface (at least not with standard functionality). It, however, is a bit confusing that $setting does not report the error -12 (An error occurred while trying to read or write to the file, registry, or environment variable.) when it cannot write or update a registry key or value. But maybe there's a reason that the error -1118 is returned in this situation. Hope this helps. Daniel


    Author: diseli (daniel.iseli@uniface.com)
  5. Hi Daniel, without any code change, starting uniface as Administrator has worked properly! Nevertheless if this functionality is requiring admin rights is not the right one for me... I must look for another path to solve my problem... Thanks Daniel and UserGho for your inputs! Best Regards, Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  6. Why not write to CURRENT_USER reg key? That should be possible.


    Author: Edu Kornmann (edu@kornmann.com)
  7. Hi Edu, nice to hear from you after all these years. Greetings from Frankfurt/Germany, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)