Hi all, I was taking another look at SHGetFolderPath() and related stuff today based on suggestions from Shanko and Zach. I think this would be fairly simple. My main question is, where do we put these values? Under File, Dir, or Shell? Or somewhere else? I vote Dir, since all the special CSIDL seem to be directories. Thus you would have something like: Dir::ADMINTOOLS Dir::BITBUCKET Dir::WINDOWS # C:\windows or C:\winnt And so on. What do you think? Regards, Dan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
Hi Dan, Daniel Berger wrote:>I was taking another look at SHGetFolderPath() and >related stuff today based on suggestions from Shanko >and Zach. I think this would be fairly simple. > >Good !>My main question is, where do we put these values? >Under File, Dir, or Shell? Or somewhere else? I vote >Dir, since all the special CSIDL seem to be >directories. > >Thus you would have something like: > >Dir::ADMINTOOLS >Dir::BITBUCKET >Dir::WINDOWS # C:\windows or C:\winnt > >And so on. > >What do you think? > >+1>Dan > >-- shanko
Shashank Date wrote:> Hi Dan, > > Daniel Berger wrote: > >> I was taking another look at SHGetFolderPath() and >> related stuff today based on suggestions from Shanko >> and Zach. I think this would be fairly simple. >> >> > Good ! > >> My main question is, where do we put these values? Under File, Dir, or >> Shell? Or somewhere else? I vote >> Dir, since all the special CSIDL seem to be >> directories. >> >> Thus you would have something like: >> >> Dir::ADMINTOOLS >> Dir::BITBUCKET >> Dir::WINDOWS # C:\windows or C:\winnt >> >> And so on. >> >> What do you think? >> >> > +1+1 Zach
Hi all, It looks like we have a consensus on using the ''Dir'' class for these - good. The docs for SHGetFolderPath() say that only "some" of the CSIDL constants are supported. It lists 16, but in my experiments many more than that are supported. However, some are not. The odd thing is that there doesn''t seem to be any rhyme or reason for why some CSIDL''s are supported and some are not. For example, I get a return value for CSIDL_MYVIDEO but not for CSIDL_MYDOCUMENTS on my Windows XP Box. Why? Dunno. So, I will just have to make sure that I document the 16 "officially" supported values, and the rest will just have to be trial and error for the users. Oh, and in case you were wondering, SHGetSpecialFolderPath() fares no better. It does worse, actually. Regards, Dan
Berger, Daniel wrote:> Hi all, > > It looks like we have a consensus on using the ''Dir'' class for these - > good. > > The docs for SHGetFolderPath() say that only "some" of the CSIDL > constants are supported. It lists 16, but in my experiments many more > than that are supported. However, some are not. > > The odd thing is that there doesn''t seem to be any rhyme or reason for > why some CSIDL''s are supported and some are not. For example, I get a > return value for CSIDL_MYVIDEO but not for CSIDL_MYDOCUMENTS on my > Windows XP Box. Why? Dunno.here''s the snippet I use to get the My Documents path on Windows Xp proc = GetProcAddress( hDll , "SHGetSpecialFolderPathA" ); //...snip.. (proc)( NULL, cPath, PATH_MYDOCUMENTS, FALSE );> > So, I will just have to make sure that I document the 16 "officially" > supported values, and the rest will just have to be trial and error for > the users. > > Oh, and in case you were wondering, SHGetSpecialFolderPath() fares no > better. It does worse, actually.If you dumpbin shell32 you can grep for all of the SHGet functions... for some odd reason there isa variation of methods for special folder paths: SHGetSpecialFolderPath SHGetSpecialFolderPathA SHGetSpecialFolderPathU Not all exist on every system, is the experience I''ve had. Zach
Hi Zach> here''s the snippet I use to get the My Documents path on Windows Xp > > proc = GetProcAddress( hDll , "SHGetSpecialFolderPathA" ); > //...snip.. (proc)( NULL, cPath, PATH_MYDOCUMENTS, FALSE );The docs say that SHGetSpecialFolderPath has been superseded by SHGetFolderPath on Win2k and later, though the docs say that Windows NT 4 SP 4 and later also support it. Where did you get "PATH_MYDOCUMENTS"? It''s not a CSIDL, but if it''s something we can rely on, I can write the code in such a way as to fall back on PATH_ macros if the CSIDL_ macro is not supported.> If you dumpbin shell32 you can grep for all of the SHGet functions... > for some odd reason there isa variation of methods for > special folder > paths: > > SHGetSpecialFolderPath > SHGetSpecialFolderPathA > SHGetSpecialFolderPathU > > Not all exist on every system, is the experience I''ve had. > > ZachSHGetSpecialFolderPath is the (older) standard function. SHGetSpecialFolderPathA is the ANSI version while SHGetSpecialFolderPathU is the Unicode version. You usually don''t call the ''A'' or ''U'' versions directly. You use SHGetSpecialFolderPath, and Windows uses either the ''A'' or ''U'' version behind the scenes, depending on the value of the UNICODE macro. At least, that''s my understanding. Regards, Dan
Berger, Daniel wrote:> Hi Zach > > >>here''s the snippet I use to get the My Documents path on Windows Xp >> >>proc = GetProcAddress( hDll , "SHGetSpecialFolderPathA" ); >>//...snip.. (proc)( NULL, cPath, PATH_MYDOCUMENTS, FALSE ); > > > The docs say that SHGetSpecialFolderPath has been superseded by > SHGetFolderPath on Win2k and later, though the docs say that Windows NT > 4 SP 4 and later also support it. > > Where did you get "PATH_MYDOCUMENTS"? It''s not a CSIDL, but if it''s > something we can rely on, I can write the code in such a way as to fall > back on PATH_ macros if the CSIDL_ macro is not supported.oops... PATH_MYDOCUMENTS is the same value as the CSIDL_MYDOCUMENTS value 0x05> > > SHGetSpecialFolderPath is the (older) standard function. > SHGetSpecialFolderPathA is the ANSI version while > SHGetSpecialFolderPathU is the Unicode version. You usually don''t call > the ''A'' or ''U'' versions directly. You use SHGetSpecialFolderPath, and > Windows uses either the ''A'' or ''U'' version behind the scenes, depending > on the value of the UNICODE macro. > > At least, that''s my understanding.That sounds about right. The only experience I have with retrieving this information is in testing of a Windows 2000 and Windows XP Professional edition OS''s for a java-based application I wrote. If I remember correctly SHGetSpecialFolder path was segfaulting my extension, but SHGetSpecialFolderA worked. It was a while ago when I wrote java extension and I can check it out again if need be, but if SHGetFolderPath is the correct way to go then please go that route. I''m just posting my experience in case it provides any help. I don''t believe I tried SHGetFolderPath back in the day. Zach
Berger, Daniel wrote:> Hi Zach > > >>here''s the snippet I use to get the My Documents path on Windows Xp >> >>proc = GetProcAddress( hDll , "SHGetSpecialFolderPathA" ); >>//...snip.. (proc)( NULL, cPath, PATH_MYDOCUMENTS, FALSE ); > > > The docs say that SHGetSpecialFolderPath has been superseded by > SHGetFolderPath on Win2k and later, though the docs say that Windows NT > 4 SP 4 and later also support it. > > Where did you get "PATH_MYDOCUMENTS"? It''s not a CSIDL, but if it''s > something we can rely on, I can write the code in such a way as to fall > back on PATH_ macros if the CSIDL_ macro is not supported.oops... PATH_MYDOCUMENTS is the same value as the CSIDL_MYDOCUMENTS value 0x05> > > SHGetSpecialFolderPath is the (older) standard function. > SHGetSpecialFolderPathA is the ANSI version while > SHGetSpecialFolderPathU is the Unicode version. You usually don''t call > the ''A'' or ''U'' versions directly. You use SHGetSpecialFolderPath, and > Windows uses either the ''A'' or ''U'' version behind the scenes, depending > on the value of the UNICODE macro. > > At least, that''s my understanding.That sounds about right. The only experience I have with retrieving this information is in testing of a Windows 2000 and Windows XP Professional edition OS''s for a java-based application I wrote. If I remember correctly SHGetSpecialFolder path was segfaulting my extension, but SHGetSpecialFolderA worked. It was a while ago when I wrote java extension and I can check it out again if need be, but if SHGetFolderPath is the correct way to go then please go that route. I''m just posting my experience in case it provides any help. I don''t believe I tried SHGetFolderPath back in the day. Zach