digitalmars.D.bugs - registry:RegQueryValueExA problem with Reserved
-
Lynn Allan
(14/14)
Sep 29 2004
- Matthew (10/24) Sep 29 2004 That function, and others, are _purely_ for internal implementation of t...
<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, </alert>
Sep 29 2004
"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, </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
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, </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
"Matthew" <admin.hat stlsoft.dot.org> 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, </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