[Oorexx-bugs] [ oorexx-Documentation-3530214 ] Value returned by WindowsRegistry r~getvalue() may be wrong

[SourceForge.net <no...@so...>]

Documentation item #3530214, was opened at 2012-05-28 03:59
Message generated for change (Comment added) made by miesfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1001880&aid=3530214&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows Extensions Reference
>Group: Next Release
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jeremy C B Nicoll (jeremynicoll)
Assigned to: Mark Miesfeld (miesfeld)
Summary: Value returned by WindowsRegistry r~getvalue() may be wrong

Initial Comment:
V4.1.1.7797, Win XP Pro

Documentation for WindowsRegistry r~getvalue() says that the "type" value that may be returned is one of a set of words, including "NONE".  I'm getting "0" when there's no matching named value.  Code works fine when named values do exist.

r = .WindowsRegistry~new              /* create a new registry object */

rexhome = value("REXX_HOME",,"ENVIRONMENT")
path2exe = rexhome || "\rexx.exe"

parent_hkcu = r~current_user
subkeynm = "Software\Microsoft\Windows\ShellNoRoam\MUICache"

accessrq = "ENUMERATE"     ,            /* to list a key's subkeys    */
           "INQUIRE"       ,            /* to list a key's values     */
           "SET"                        /* to create/delete/set value */

handle_sbky = r~open(parent_hkcu,subkeynm,accessrq)
grab1.   = r~getvalue(handle_sbky,path2exe)
call l "grabbed subkey value for path2exe='"path2exe"'"
call l "  which is: type='"grab1.type"' and data='"grab1.data"'"
r~close(handle_sbky)

logs text:

20120528 09:29:30.531000 grabbed subkey value for path2exe='C:\My Dropbox\Programs-IPCLP\~open-source ooRexx V4-1-1\rexx.exe'
20120528 09:29:30.546000   which is: type='0' and data='0'
20120528 09:29:30.546000   which is not expected (NORMAL) type.

whereas a found value would log something like:

20120528 09:29:30.546000 grabbed subkey value for path2exe='C:\My Dropbox\Programs-IPCLP\~open-source ooRexx V4-1-1\rexxhide.exe'
20120528 09:29:30.546000   which is: type='NORMAL' and data='Open Object Rexx Interface'

It's perfectly reasonnable that the value wasn't found, but I was expecting a type of "NONE" in that instance, if I've interpreted the documentation correctly.


----------------------------------------------------------------------

>Comment By: Mark Miesfeld (miesfeld)
Date: 2012-05-28 21:11

Message:
Committed revision 7808.
Committed revision 7809.  bug fix branch

----------------------------------------------------------------------

Comment By: Jeremy C B Nicoll (jeremynicoll)
Date: 2012-05-28 15:55

Message:
"All it takes is a text editor..."    Presumably the real stumbling block
is whether one can understand the ins & outs of what the source code
means...    No-one's going to write good doc just by describing what a
small number of test execs appear to show.  My understanding of C isn't all
that good (I know that from having got the wrong end of the stick looking
at source for other things in the past).  It also depends on whether
there;'s proper commenting.  And whether one has to understand lots of the
whole app/project to be able to read any section of it with comprehension. 
 I once looked at a Regina interpreter and realised it was far less obvious
than I'd hoped what was going in in that (and I have a degree in Comp Sci
that's OS and interpreters & compilers orientated so it wasn't the cincepts
that were the problem).

----------------------------------------------------------------------

Comment By: Mark Miesfeld (miesfeld)
Date: 2012-05-28 15:34

Message:
The doc for open() says it returns 0 on failure.  So check the return for
open() , if it failed, further calls will not work.

The documentation for WinRegistry, and most likely the other Windows
Extensions doc, has the same problem as ooDialog did / does.  It is
incomplete, misleading, and often flat wrong.  This is the way we got it
from IBM.  

I've rewritten almost all of the ooDialog doc to correct the problem.  I
will eventually tackle the other extensions, but not until I finish
ooDialog.  However, this is an area where any user of ooRexx could
contribute.  All it takes to help correct the doc is a text editor and a
small learning curve.

I would encourage you to open up a discussion on the user list where I will
gladly help anyone with the details of how to contribute to the ooRexx
documentation.

----------------------------------------------------------------------

Comment By: Jeremy C B Nicoll (jeremynicoll)
Date: 2012-05-28 13:33

Message:
OK, thanks for solution.   When fixing the doc will you explain if the same
thing applies to any/all other similar registry-handling functions?  Nealry
none of them are docced in terms of what happens on failure.  

Eg I also found that if you've got the wrong access level (ie didn't code
the right things on the ~open(), other calls go wrong silently.  Eg a
setvalue() will not tell you if it worked; I got around that by doing
another getvalue() after each setvalue() to see if the value had changed. 
It might be better if there was an attribute of the registry object that
says whether the last operation worked.

----------------------------------------------------------------------

Comment By: Mark Miesfeld (miesfeld)
Date: 2012-05-28 11:29

Message:
What the docs don't mention is that 0 is returned on error.  Change your
code to something like this:

r = .WindowsRegistry~new /* create a new registry object */

rexhome = value("REXX_HOME",,"ENVIRONMENT")
 path2exe = rexhome || "\rexx.exe"

parent_hkcu = r~current_user
 subkeynm = "Software\Microsoft\Windows\ShellNoRoam\MUICache"

accessrq = "ENUMERATE" , /* to list a key's subkeys */
 "INQUIRE" , /* to list a key's values */
 "SET" /* to create/delete/set value */

handle_sbky = r~open(parent_hkcu,subkeynm,accessrq)
 -- grab1. = r~getvalue(handle_sbky,path2exe)

 retVal = r~getvalue(handle_sbky,path2exe)
 if retVal~isA(.stem) then do
   say 'got a good return'
   grab1. = retVal
 end
 else do
   say 'got an error return, quitting'
   r~close(handle_sbky)
   return 99
 end

 call l "grabbed subkey value for path2exe='"path2exe"'"
 call l " which is: type='"grab1.type"' and data='"grab1.data"'"


 r~close(handle_sbky)


::requires winsystm.cls

If you don't like the retVal~isA() method, you could use this:

 if retVal \== 0 then do

but I think checking that a stem is returned makes the code more obvious as
to what it is doing.

I'm going to change this to a documentation bug and will update the doc.

As an aside, I'm glad that you are taking an active role with ooRexx.  In
the future if you would attach a working test case that demonstrates the
bug, rather than copy and paste in a snippet of you code, it is much easier
for one of the developers to investigate.  Easier translates directly to
"more likely" to investigate.

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1001880&aid=3530214&group_id=119701