On Fri, 17 Dec 2004 12:04:46 +0100 (CET), you wrote:
Hi Dmitry,
pvriens@xs4all.nl wrote:
trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000
...
trace:shell:SHGetPathFromIDListW -- L"F:\temp", 0x00000000
The main difference (apart from the A/W) is that SHGetPathFromIDListW returns an extra backslash compared to the A-counterpart.
If you mean a double backslash in the 2nd line of the above quote then it's just the escaping which debugtsr_w() performs.
-- Dmitry.
I think the problem lies in the fact the some of the procedures use Unicode depending on the version and some don't care (or use some default). Going to the traces I can see:
Call shell32.SHBrowseForFolder(3de5f760) ret=01003c8d ... (always calls SHBrowseForFolderA) trace:shell:SHBrowseForFolderA Ret shell32.SHBrowseForFolder() retval=77e30fc0 ret=01003c8d ... Call shell32.SHGetPathFromIDList(77e30fc0,0100b720) ret=01003c99 trace:shell:SHGetPathFromIDListAW ... (checking the version) trace:shell:SHGetPathFromIDListW ... Ret shell32.SHGetPathFromIDList() retval=00000001 ret=01003c99 ... Call kernel32.lstrcpyA(0100a360,0100b720 "F") ret=01003ca9
So you see, we are mixing A and W now:
- SHBrowseForFolderA
- SHGetPathFromIDListW
- lstrcpyA
In this case does it mean we (I ?) have to implement SHBrowseForFolderAW or is that the wrong path (as many calls don't do this and all of them have to be checked/corrected)?
SHGetPathFromIDList seems to be the wrong one here (looking at native shell32.dll from Win2K and Win98), it should be synonymous for SHGetPathFromIDListA.
Can you try attached patch?
Rein.