hi Juergen,
I chose SHGetRegPathW from shlwapi, because that seemed to be the best
matching function for getting the registry string. I did not call a *AW
function directly. I fixed the SHQueryValueExW to convert the incoming
strings to ascii, _because_ the SHQueryValueExAW function had a bug in
handling ExpandEnviromentStringsA (always failed) and was ascii-only (it
doesn't seem to handle unicode at all). That was also the part i was not
completely happy about. I must say i'm not to happy about including
shlwapi either, but i think it is better than reinventing the wheel.
What would you suggest i do? Move SHGetRegPath into a libwine and make a
dependency from shlwapi and compobj(ole32) to that library? reimplement
SHGetRegPathW and SHQueryValueExW in place in compobj.c ? Especially
with the lib seperation going on.. there will be more and more inter-dll
dependencys, must we avoid that at all cost?
regards,
leo
[EMAIL PROTECTED] wrote:
>Hmm, I think ole32 must not import shlwapi.dll...
>Instead after the RegQueryValue call it should do a ExpandEnvironmentStrings when
>returned lpType is REG_EXPAND_SZ.
>
>... and never ever call a *AW Function internally, it will behave differently (one
>time it takes ASCII one time UNICODE) depending on the OSVERSION ...
>
>Juergen
>
>On 12 Apr 2002 at 20:17, Leo van den berg wrote:
>
>>Cleaned up and fixxed Registry Path finding of Inprocess32 & LocalServer32,
>>registry entrys like '%SystemRoot%' don't break programs anymore now.
>>Found that SHQueryValueEx - family of functions were broken (and derived
>>functions as well ofcourse). Not 100% happy about the result, but it seems
>>to *work* now.
>>
>>any comments welcome ofcourse,
>> Leo van den Berg
>>
>
>
