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

"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.

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

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