#762 .WindowsRegistry listValues misnames stem.1.name


In the program below, the .WindowsRegistry listValues() method creates "lv.1" but instead should create "lv.1.name", for example.

By the way, it's documentation could more clearly state that the result is not a stem of stems, but instead is a
stem which has keys which only look like stems (since they contain periods as in "1.type").

I'm running REXX-ooRexx_4.0.0(MT) 6.03 30 Jun 2009 in an up to date Vista.

signal on novalue
trace e

rg = .WindowsRegistry~new

objectrexxkey = rg~open(rg~current_user, 'Software\Microsoft\Command Processor', 'READ WRITE')
say objectrexxkey -- Says 0x000001B8

qstem. = rg~query(objectrexxkey)
say qstem. -- Says RETSTEM.
say 'qstem.values:' qstem.values -- Says qstem.values: 4
a = ''
do k over qstem.
a = a k
say 'qstem.:' a -- Says qstem.: TIME DATE VALUES SUBKEYS CLASS

say rg~listValues(objectrexxkey,lv.) -- Says 0
a = ''
do k over lv.
a = a k
say 'lv.:' a -- Error: Says lv.: 2 1 3 1.TYPE 1.DATA 4 2.TYPE 3.TYPE 4.TYPE 4.DATA 3.DATA 2.DATA

say lv.1 -- Says CompletionChar
say lv.1.type -- Says NUMBER
say lv.1.data -- Says 6
say lv.1.name -- Says Error 16.1: Label "NOVALUE" not found

::requires WinSystm.cls


  • Mark Miesfeld

    Mark Miesfeld - 2009-07-14

    I'll take a look at this.

  • Mark Miesfeld

    Mark Miesfeld - 2009-07-15

    Committed revision 4923.

    Thanks again Doug. This is fixed now.

    On the documentation, I'm not quite sure what you are getting at. In your example, lv. is a stem. Some of the tails of the stem are assigned values, but out of all conceivable tails, most are not assigned values. What is assigned a value, are the tails that the documentation says will be assigned a value.

    For instance, with the bug fixed, lv.1.name is assigned a value. But there is nothing in the doc that indicates lv.1 is going to be assigned a value, and it shouldn't be assigned a value.

    With the bug fixed, I get this from do k over lv.

    lv.*: 1.NAME 1.DATA 1.TYPE 2.NAME 2.TYPE 2.DATA 3.NAME 3.TYPE 3.DATA

    that is what is expected.

    What you got before the bug was fixed was:

    lv.*: 2 1 3 1.TYPE 1.DATA 4 2.TYPE 3.TYPE 4.TYPE 4.DATA 3.DATA 2.DATA

    That was also correct, because with the bug, lv.1, .lv.2, and lv.3 were being assigned a value, but lv.1.name, lv.2.name, and lv.3.name were not being assigned a value.

    Anyhow, thanks again, I'll look and the doc and see if I can add anything that clarifies it.

  • Anonymous - 2009-07-15

    About the documentation:
    Perhaps I'm just not familiar enough with working with names such as "a.b.c".
    That name looks like there's a stem "a" (really "a.") which has a sub-key "b" which is a stem which has a sub-key "c".
    So it looks like I could write code such as the following, incorrect example:

    i = 1
    t = 'type'
    say lv.i.t

    I'm not much of a wordsmith, but a suggestion for casual users like me is to change:
    "The suffixes of the compound variable are numbered starting with 1, and for each
    number the three values are the name (var.i.name), the data (var.i.data), and the type (var.i.type)."
    "Each key is represented by 3 values [sp?] in the stem.
    The first part of each stem suffix is an integer identifying the which key, numbered from 1.
    That is concatenated with a dot (.) and one of 3 words: "NAME", "TYPE", and "DATA".
    For example: var.1.name, var.1.type, var.1.data, var.2.name, ....".

  • Mark Miesfeld

    Mark Miesfeld - 2009-07-15


    Okay, I see what you are saying. But, take this code:

    r = reg~listValues(key, vals.)

    nameIndex = name
    typeStemName = type
    dataThing = data
    do i = 1 to count
    say 'Value name:' vals.i.nameIndex
    say 'Value type:' vals.i.typeStemName
    say 'Value data:' vals.i.dataThing

    It produces exactly what you, and I, would expect:

    Value name: CompletionChar
    Value type: NUMBER
    Value data: 9
    Value name: DefaultColor
    Value type: NUMBER
    Value data: 0
    Value name: EnableExtensions
    Value type: NUMBER
    Value data: 1

    This also works as you expect:

    nameIndex = 'NAME'

    So, it has to do with the case, not whether it is a stem or not. I forget the exact rules for case with stem collections. It works exactly the same way under 3.2.0, so I don't think it is a bug.

  • Rick McGuire

    Rick McGuire - 2009-07-15

    Compound variables are a flat namespace. As Mark surmised, only the tail values that set are (well), set. It really is an error to think of these as a hierarchy. And, yes, they are case sensitive.

    A better original approach might have been to have returned an array of directories (or even a real, special purpose object). Had it been implemented this way, then you could have manipulated individual values as a unit. For compatibility reasons, this obviously cannot be done now, but it might be interesting to explore a new version of this class that did behave this way.

  • Mark Miesfeld

    Mark Miesfeld - 2010-02-19

    The fix for this item was in the 4.0.0 release.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks