#762 .WindowsRegistry listValues misnames stem.1.name

v4.0
closed
5
2012-08-14
2009-07-14
No

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
end
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
end
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

Discussion

  • 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)."
    to:
    "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

    Doug,

    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
    end

    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.

     


Anonymous

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