Re: [Boost-build] Win32 registry functions

From: Bojan Resnik (resnikb_at_[hidden])
Date: 2006-09-08 16:16:24

> FYI... I'm only bugging you about the interface because I hate to add to
> many extra builtins. The simpler that interface is the better for users.
> So I'm not objecting to needing the functionality :-)

  No problem, I would also like to have a simple and functional interface :)

> Well to Windows they may be different beasts, but is there a conceptual
> difference between them? That is isn't the key/name=value equivalent to
> key/name/value. For example, one that intentionally has both values and
> subkeys. With you functions:
>
> appearance =
>    [ W32_REGVALUES "HKCU\\Control Panel\\Appearance" ]
>    [ W32_REGKEYS "HKCU\\Control Panel\\Appearance" ] ;
> for a in $(appearance) {
>    ECHO $(a) == [ W32_GETREG $(a) ] ;

Should be:
    ECHO $(a) == [ W32_GETREG "HKCU\\Control Panel\\Appearance" : $(a) ] ;

> }

In the above example, what would
   [ W32_GETREG "HKCU\\Control Panel\\Appearance" : "x" ]
return: data contained in value "x" of HKCU\Control Panel\Appearance
registry key, or the default value of HKCU\Control Panel\Appearance\x
key?
  As Phillip mentioned, a registry key can have a subkey and a value
with the same name. For this reason, they need to be separated
somehow.

> That said... I'm not against having three different types of results
> made available, i.e. values, value names, and subkeys. But if it's
> really needed I'd rather have a single builtin rule that handles all
> those case. For example like I did the SHELL rule. In this case I'd prefer:
>
> rule W32_GETREG ( path : default ? : result-type ? )
> #  result-type = <empty> | keys | value-names

  In this case, the "result-type" and "default" parameters are
mutually exclusive and using the rule could become more complex:
  W32_GETREG "HKCU\\Environment" : keys
would return the data contained in the value "keys" of registry key
"HKCU\Environment" while
  W32_GETREG "HKCU\\Environment" : : keys
would return list of subkeys of that element. On the other hand, something like
  W32_GETREG "HKCU\\Environment" : a : keys
would be an error

How about a rule like:
   W32_GETREGNAMES ( path : result-type )
#  result-type = subkeys | values

which adds only one new builtin?

-- 
Bojan Resnik