www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - registry:RegQueryValueExA problem with Reserved

reply "Lynn Allan" <l_d_allan adelphia.net> writes:
<alert comment="newbie">

I gave std.windows.registry a try while preparing some dsource tutorial
code, but had problems (and perhaps gave up too quickly).

* There were conflicts/redundancies between registry.d and windows.d

* The first function I tried had an apparent compiler error, which reduced
my confidence in the code. I think there should be a variable name to go
along with Reserved.

#LONG  RegQueryValueExA(in HKEY hkey,
#             in LPCSTR lpValueName,
#             in Reserved,   // <-- won't compile
#             out REG_VALUE_TYPE type,
#             in void *lpData,
#             inout DWORD cbData);

</alert>
Sep 29 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Lynn Allan" <l_d_allan adelphia.net> wrote in message
news:cjeb8h$ua8$1 digitaldaemon.com...
 <alert comment="newbie">

 I gave std.windows.registry a try while preparing some dsource tutorial
 code, but had problems (and perhaps gave up too quickly).

 * There were conflicts/redundancies between registry.d and windows.d

 * The first function I tried had an apparent compiler error, which reduced
 my confidence in the code. I think there should be a variable name to go
 along with Reserved.

 #LONG  RegQueryValueExA(in HKEY hkey,
 #             in LPCSTR lpValueName,
 #             in Reserved,   // <-- won't compile
 #             out REG_VALUE_TYPE type,
 #             in void *lpData,
 #             inout DWORD cbData);

 </alert>

That function, and others, are _purely_ for internal implementation of the std.windows.registry classes. (The reason they're not private is that the lib is *very* old, in D terms anyway.) The std.windows.registry module is intended to be used through the class based interface: Key, Value, KeyNameSequence, KeySequence, ValueSequence, ValueNameSequence, Registry. The code's been thoroughly tested over the last 18 months, and there are no problems with it that should shake anyone's confidence. Any conflicts between it and std.windows.windows.d, which I don't experience btw, will be as a consequence of things being added to windows.d without concomitant changes to registry.d Can you be specific about the problems you found, and I'll attempt to address them in a future update? What "conflicts"? What was the compiler error? etc.
Sep 29 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
FYI, I'll be doing an update to this lib - including privatising the helpers,
and providing D-like docs - among several, 
as soon as (i)
I've done the exception stuff (next on the list), and (ii) written a simple
Ruby script to produce D-like docs from
"enhanced" Doxygen tags.

Hopefully sometime early next week.

:')

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cjf7qj$1h6u$1 digitaldaemon.com...
 "Lynn Allan" <l_d_allan adelphia.net> wrote in message
news:cjeb8h$ua8$1 digitaldaemon.com...
 <alert comment="newbie">

 I gave std.windows.registry a try while preparing some dsource tutorial
 code, but had problems (and perhaps gave up too quickly).

 * There were conflicts/redundancies between registry.d and windows.d

 * The first function I tried had an apparent compiler error, which reduced
 my confidence in the code. I think there should be a variable name to go
 along with Reserved.

 #LONG  RegQueryValueExA(in HKEY hkey,
 #             in LPCSTR lpValueName,
 #             in Reserved,   // <-- won't compile
 #             out REG_VALUE_TYPE type,
 #             in void *lpData,
 #             inout DWORD cbData);

 </alert>

That function, and others, are _purely_ for internal implementation of the std.windows.registry classes. (The reason they're not private is that the lib is *very* old, in D terms anyway.) The std.windows.registry module is intended to be used through the class based interface: Key, Value, KeyNameSequence, KeySequence, ValueSequence, ValueNameSequence, Registry. The code's been thoroughly tested over the last 18 months, and there are no problems with it that should shake anyone's confidence. Any conflicts between it and std.windows.windows.d, which I don't experience btw, will be as a consequence of things being added to windows.d without concomitant changes to registry.d Can you be specific about the problems you found, and I'll attempt to address them in a future update? What "conflicts"? What was the compiler error? etc.

Sep 29 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
I've adjusted this, and will be sending along to Walter along with several
updates very shortly.

When they hit Phobos, though, is out of my control ... :-)

Thanks for the feedback

Cheers

Matthew

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cjfb02$1jfg$1 digitaldaemon.com...
 FYI, I'll be doing an update to this lib - including privatising the helpers,
and providing D-like docs - among 
 several, as soon as (i)
 I've done the exception stuff (next on the list), and (ii) written a simple
Ruby script to produce D-like docs from
 "enhanced" Doxygen tags.

 Hopefully sometime early next week.

 :')

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cjf7qj$1h6u$1 digitaldaemon.com...
 "Lynn Allan" <l_d_allan adelphia.net> wrote in message
news:cjeb8h$ua8$1 digitaldaemon.com...
 <alert comment="newbie">

 I gave std.windows.registry a try while preparing some dsource tutorial
 code, but had problems (and perhaps gave up too quickly).

 * There were conflicts/redundancies between registry.d and windows.d

 * The first function I tried had an apparent compiler error, which reduced
 my confidence in the code. I think there should be a variable name to go
 along with Reserved.

 #LONG  RegQueryValueExA(in HKEY hkey,
 #             in LPCSTR lpValueName,
 #             in Reserved,   // <-- won't compile
 #             out REG_VALUE_TYPE type,
 #             in void *lpData,
 #             inout DWORD cbData);

 </alert>

That function, and others, are _purely_ for internal implementation of the std.windows.registry classes. (The reason they're not private is that the lib is *very* old, in D terms anyway.) The std.windows.registry module is intended to be used through the class based interface: Key, Value, KeyNameSequence, KeySequence, ValueSequence, ValueNameSequence, Registry. The code's been thoroughly tested over the last 18 months, and there are no problems with it that should shake anyone's confidence. Any conflicts between it and std.windows.windows.d, which I don't experience btw, will be as a consequence of things being added to windows.d without concomitant changes to registry.d Can you be specific about the problems you found, and I'll attempt to address them in a future update? What "conflicts"? What was the compiler error? etc.


Sep 29 2004