Hello,

I have applications which use system variables, e.g. CSIDL_COMMON_DOCUMENTS 
for "C:\Documents and Settings\All Users\Documents". How can I transfer 
these for running on VISTA?

Thanks.

-- 
John

John Schmidt wrote:
> I have applications which use system variables, e.g.
> CSIDL_COMMON_DOCUMENTS for "C:\Documents and Settings\All
> Users\Documents". How can I transfer these for running on VISTA?

John,

Just continue to use CSIDL_..... Vista supports these constants for 
backward compatibility.

Not sure, but I think CSIDL_COMMON_DOCUMENTS translates to
C:\users\public\documents on Vista. (I don't have Vista accessible 
right now)

Regards
Tom

John Schmidt wrote:
> I have applications which use system variables, e.g.
> CSIDL_COMMON_DOCUMENTS for "C:\Documents and Settings\All
> Users\Documents". How can I transfer these for running on VISTA?

John,
 Forgot to say: this link provides additional info:
http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx

Regards
Tom

> Not sure, but I think CSIDL_COMMON_DOCUMENTS translates to
> C:\users\public\documents on Vista. (I don't have Vista accessible
> right now)

Thanks Tom, I have found the document. As there is no word about the new 
physical path I'm very glad about your suggestion. I still don't use Vista 
for it's bugs, so I don't know anything about the new paths. Same time I 
need to make my applications Vista-enabled for clients who have Vista.

Regards,

-- 
John

> {quote:title=Tom Brunberg wrote:}{quote}
> John Schmidt wrote:
> > I have applications which use system variables, e.g.
> > CSIDL_COMMON_DOCUMENTS for "C:\Documents and Settings\All
> > Users\Documents". How can I transfer these for running on VISTA?
> 
> John,
>  Forgot to say: this link provides additional info:
> http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
> 

There are a few pitfalls with regards to these (diiference in behaviour between XP, Server 2003 and Vista).
[http://lists.runrev.com/pipermail/use-revolution/2007-February/094217.html|http://lists.runrev.com/pipermail/use-revolution/2007-February/094217.html]
which also points to: http://msdn.microsoft.com/en-us/library/ms995853.aspx

--
http://Lars.Fosdal.com - There are no stupid questions

"Tom Brunberg" <nospam@to.me> wrote in message 
news:6311@forums.codegear.com...

> Just continue to use CSIDL_..... Vista supports these constants
> for backward compatibility.

Only to an extent, since CSIDL is deprecated in Vista.  Vista uses 
KNOWNFOLDERID now, complete with a new set of API functions for working with 
KNOWNFOLDERID values.  Not all CSIDLs have a 1-to-1 KNOWNFOLDERID 
equivilent.


Gambit

Remy Lebeau (TeamB) wrote:
> "Tom Brunberg" <nospam@to.me> wrote in message
> news:6311@forums.codegear.com...
>
>> Just continue to use CSIDL_..... Vista supports these constants
>> for backward compatibility.
>
> Only to an extent, since CSIDL is deprecated in Vista.  Vista uses
> KNOWNFOLDERID now, complete with a new set of API functions for
> working with KNOWNFOLDERID values.  Not all CSIDLs have a 1-to-1
> KNOWNFOLDERID equivilent.

So, in the context of the OP, what is your recommendation?

In addition to the pitfalls that Lars pointed out in this same thread, 
are there other matters to consider?

I'm still using D2005, so a few practical questions:
From which version of Delphi is the known folder system available?
Will an application, that is developed with that Delphi version and 
using the known folder system, be compatible with WinXP, Win2003 and 
Win2k?

Regards
Tom

Lars Fosdal wrote:

> There are a few pitfalls with regards to these (diiference in
> behaviour between XP, Server 2003 and Vista).
> [http://lists.runrev.com/pipermail/use-revolution/2007-February/094217.html|http://lists.runrev.com/pipermail/use-revolution/2007-February/094217.html]
> which also points to:
> http://msdn.microsoft.com/en-us/library/ms995853.aspx

Lars,

Thank you for filling up with this info.

Regards
Tom

"Tom Brunberg" <nospam@to.me> wrote in message 
news:6627@forums.codegear.com...

> So, in the context of the OP, what is your recommendation?

    KNOWNFOLDERID
    http://msdn.microsoft.com/en-us/library/bb762584(VS.85).aspx

    FOLDERID_PublicDocuments
    GUID: {ED4824AF-DCE4-45A8-81E2-FC7965083634}
    Display Name: Public Documents
    Folder Type: COMMON
    Default Path: %PUBLIC%\Documents
    CSIDL Equivalent: CSIDL_COMMON_DOCUMENTS
    Legacy Display Name: Shared Documents
    Legacy Default Path: %ALLUSERSPROFILE%\Documents

> From which version of Delphi is the known folder system available?

None.  You will have to declare the types and link to the new API functions 
manually.


Gambit

Remy Lebeau (TeamB) wrote:
> "Tom Brunberg" <nospam@to.me> wrote in message
> news:6627@forums.codegear.com...
>
>> So, in the context of the OP, what is your recommendation?
>
>    KNOWNFOLDERID
>    http://msdn.microsoft.com/en-us/library/bb762584(VS.85).aspx
>
>    FOLDERID_PublicDocuments
>    GUID: {ED4824AF-DCE4-45A8-81E2-FC7965083634}
>    Display Name: Public Documents
>    Folder Type: COMMON
>    Default Path: %PUBLIC%\Documents
>    CSIDL Equivalent: CSIDL_COMMON_DOCUMENTS
>    Legacy Display Name: Shared Documents
>    Legacy Default Path: %ALLUSERSPROFILE%\Documents
>
>> From which version of Delphi is the known folder system available?
>
> None.  You will have to declare the types and link to the new API
> functions manually.
>

My third question fell out of scope since the answer to the second was 
"none"
So, let me refrace it:
Will this solution run on anything before Vista?

Tom

"Tom Brunberg" <nospam@to.me> wrote in message 
news:6658@forums.codegear.com...

> Will this solution run on anything before Vista?

No. KNOWNFOLDERID, and the corresponding APIs, are new to Vista.


Gambit

Remy Lebeau (TeamB) wrote:
> "Tom Brunberg" <nospam@to.me> wrote in message
> news:6658@forums.codegear.com...
> 
>> Will this solution run on anything before Vista?
> 
> No. KNOWNFOLDERID, and the corresponding APIs, are new to Vista.
> 

Thank you Gambit, for the info.
I guess I'm stuck with the CSIDLs then, as so many others.

Regards
Tom

You could query for the OS version and have a set of calls for XP and 
earlier and another set for Vista.

-- 

-----Jon-----


"Tom Brunberg" <nospam@to.me> wrote in message 
news:6676@forums.codegear.com...
> Remy Lebeau (TeamB) wrote:
>> "Tom Brunberg" <nospam@to.me> wrote in message
>> news:6658@forums.codegear.com...
>>
>>> Will this solution run on anything before Vista?
>>
>> No. KNOWNFOLDERID, and the corresponding APIs, are new to Vista.
>>
>
> Thank you Gambit, for the info.
> I guess I'm stuck with the CSIDLs then, as so many others.
>
> Regards
> Tom
>

Jon Springs wrote:
> You could query for the OS version and have a set of calls for XP 
> and
> earlier and another set for Vista.

Jon,

And what would be the benefit from doing that?

Well, in article
http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
it is stated:
----
CSIDL
Note  In Windows Vista, these values have been replaced by 
KNOWNFOLDERID values. See that topic for a list of the new constants 
and their corresponding CSIDL values. For convenience, corresponding 
KNOWNFOLDERID values are also noted here for each CSIDL value.
The CSIDL system is supported under Windows Vista for compatibility 
reasons. However, new development should use KNOWNFOLDERID values 
rather than CSIDL values.
----
Looking through the list all CSIDL values have a corresponding 
KNOWNFOLDERID value.


The relevant articles on msdn for
SHGetFolderLocation Function and
SHGetFolderPath Function
states:
----
Note  As of Windows Vista, this function is merely a wrapper for 
SHGetKnownFolderPath. The CSIDL value is translated to its associated 
KNOWNFOLDERID and then SHGetKnownFolderPath is called. New 
applications should use the known folder system rather than the older 
CSIDL system, which is supported only for backward compatibility.
----


So, if the application should run on both XP and Vista, there's no 
point in checking the OS and provide different calls because
- The CSIDL system is supported on both
- On Vista the OS translates the CSIDL call to a KNOWNFOLDERID call so 
the effect is the same as you would be using different calls.


The article that Lars pointed out in another branch of this thread was 
not actually about using the CSIDL system on a Vista machine, but 
rather which CSIDL to use to be able to read/store files on a Server 
2003. To use a special KNOWNFOLDERID call (on Vista) would not have 
solved the problem mentioned.
In fact, after changing the wrong CSIDL (CSIDL_COMMON_APPDATA) to the 
correct one (CSIDL_COMMON_DOCUMENTS) for the purpose they used it, 
they say "I tested it on 2000, XP and VISTA and our install worked 
excellent." Unfortunately then, this did not work on Server 2003.


Regards
Tom

You could retain your current code and expect it to continue working while 
also adjusting to the new methodology of Vista.

-- 

-----Jon-----


"Tom Brunberg" <nospam@to.me> wrote in message 
news:6726@forums.codegear.com...
> Jon Springs wrote:
>> You could query for the OS version and have a set of calls for XP
>> and
>> earlier and another set for Vista.
>
> Jon,
>
> And what would be the benefit from doing that?
>
> Well, in article
> http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
> it is stated:
> ----
> CSIDL
> Note  In Windows Vista, these values have been replaced by
> KNOWNFOLDERID values. See that topic for a list of the new constants
> and their corresponding CSIDL values. For convenience, corresponding
> KNOWNFOLDERID values are also noted here for each CSIDL value.
> The CSIDL system is supported under Windows Vista for compatibility
> reasons. However, new development should use KNOWNFOLDERID values
> rather than CSIDL values.
> ----
> Looking through the list all CSIDL values have a corresponding
> KNOWNFOLDERID value.
>
>
> The relevant articles on msdn for
> SHGetFolderLocation Function and
> SHGetFolderPath Function
> states:
> ----
> Note  As of Windows Vista, this function is merely a wrapper for
> SHGetKnownFolderPath. The CSIDL value is translated to its associated
> KNOWNFOLDERID and then SHGetKnownFolderPath is called. New
> applications should use the known folder system rather than the older
> CSIDL system, which is supported only for backward compatibility.
> ----
>
>
> So, if the application should run on both XP and Vista, there's no
> point in checking the OS and provide different calls because
> - The CSIDL system is supported on both
> - On Vista the OS translates the CSIDL call to a KNOWNFOLDERID call so
> the effect is the same as you would be using different calls.
>
>
> The article that Lars pointed out in another branch of this thread was
> not actually about using the CSIDL system on a Vista machine, but
> rather which CSIDL to use to be able to read/store files on a Server
> 2003. To use a special KNOWNFOLDERID call (on Vista) would not have
> solved the problem mentioned.
> In fact, after changing the wrong CSIDL (CSIDL_COMMON_APPDATA) to the
> correct one (CSIDL_COMMON_DOCUMENTS) for the purpose they used it,
> they say "I tested it on 2000, XP and VISTA and our install worked
> excellent." Unfortunately then, this did not work on Server 2003.
>
>
> Regards
> Tom

Jon Springs wrote:
> You could retain your current code and expect it to continue working
> while also adjusting to the new methodology of Vista.

Yes, I can agree with that, in a time frame of a few years.
The utmost concern for my clients and me, is anyway compatibility over 
2-3 latest OS generations.

Best regards
Tom

"Jon Springs" <jspringsATjontandsheDOTorg> wrote in message 
news:6693@forums.codegear.com...

> You could query for the OS version and have a set of
> calls for XP and earlier and another set for Vista.

It is generally not a good idea to rely on version numbers like that.  It is 
better to dynamically load the desired functions at runtime instead.  They 
will either exist or they won't, and you can act accordingly.  This also 
allows you the oppurtunity to write compatibility DLLs if you want to 
manually expose newer API functions in older OS versions, for instance.


Gambit

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:6955@forums.codegear.com...
> "Jon Springs" <jspringsATjontandsheDOTorg> wrote in message 
> news:6693@forums.codegear.com...
>
>> You could query for the OS version and have a set of
>> calls for XP and earlier and another set for Vista.
>
> It is generally not a good idea to rely on version numbers like that.

> Gambit

Why would you say that is?

-----Jon-----

"Jon Springs" <jsprings@jontandshe.org> wrote in message 
news:6964@forums.codegear.com...

> Why would you say that is?

Because:

1) It is not necessary to do that, as dynamic loading accomplishes the same 
goal in a more reliable and stable manner

2) Microsoft says not to do it anyway:

    GetVersionEx Function
    http://msdn.microsoft.com/en-us/library/ms724451(VS.85).aspx

    "Identifying the current operating system is usually not the best way to 
determine whether a particular operating system feature is present. This is 
because the operating system may have had new features added in a 
redistributable DLL. Rather than using GetVersionEx to determine the 
operating system platform or version number, test for the presence of the 
feature itself. For more information, see Operating System Version 
(http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspx)."


Gambig

Oh, seems a bit odd to me.

> Gambig
? ;-)

-- 

-----Jon-----

"Jon Springs" <jsprings@jontandshe.org> wrote in message 
news:7044@forums.codegear.com...

> Oh, seems a bit odd to me.

What is odd about it?  If you want to use a particular function, why should 
you care what specific version(s) have it?  You can test whether the actual 
function exists or not, without caring what the particular OS version is, 
and then act accordingly.  That is the correct way to handle it.


Gambit

Then why go to the trouble of providing version number functions?

-- 

-----Jon-----


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:7486@forums.codegear.com...
> "Jon Springs" <jsprings@jontandshe.org> wrote in message 
> news:7044@forums.codegear.com...
>
>> Oh, seems a bit odd to me.
>
> What is odd about it?  If you want to use a particular function, why 
> should you care what specific version(s) have it?  You can test whether 
> the actual function exists or not, without caring what the particular OS 
> version is, and then act accordingly.  That is the correct way to handle 
> it.
>
>
> Gambit
>

> What is odd about it?  If you want to use a particular function, why 
> should you care what specific version(s) have it?  You can test whether 
> the actual function exists or not, without caring what the particular OS 
> version is, and then act accordingly.  That is the correct way to handle 
> it.

Hi Gambit,

But how to handle style params like in the CreateParams, e.g.:

  if WinXPOrHigher then
    Params.WindowClass.Style := Params.WindowClass.Style or CS_DROPSHADOW;

How can I check for there existence?

Regards,
John

"Jon Springs" <jspringsATjontandsheDOTorg> wrote in message 
news:7634@forums.codegear.com...

> Then why go to the trouble of providing version number functions?

So you can report version numbers to the user, log files, etc.  The code 
shouldn't act on them, though.


Gambit

"John Schmidt" <schmidtjohn@yahoo.com> wrote in message 
news:7765@forums.codegear.com...

> But how to handle style params like in the CreateParams, e.g.:
>
>  if WinXPOrHigher then
>    Params.WindowClass.Style := Params.WindowClass.Style or CS_DROPSHADOW;
>
> How can I check for there existence?

That is a completely different issue.  We're talking about detecting the 
presense of API functions at runtime, not the availability of window styles. 
You can't query those dynamically like you can with functions.  So checking 
version numbers is the only way to do that.


Gambit

> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> "Jon Springs" <jspringsATjontandsheDOTorg> wrote in message 
> news:6693@forums.codegear.com...
> 
> > You could query for the OS version and have a set of
> > calls for XP and earlier and another set for Vista.
> 
> It is generally not a good idea to rely on version numbers like that.  It is 
> better to dynamically load the desired functions at runtime instead.  They 
> will either exist or they won't, and you can act accordingly.  This also 
> allows you the oppurtunity to write compatibility DLLs if you want to 
> manually expose newer API functions in older OS versions, for instance.
> 
> 
> Gambit

As a newbie to this stuff, I would very much appreciate a code snippet on how to do this the right way (function GetSharedDucomentsFolder: string).


Thanks in advance

Steen

Steen Albrechtsen wrote:
[]
> As a newbie to this stuff, I would very much appreciate a code
> snippet on how to do this the right way (function
> GetSharedDucomentsFolder: string).
>
>
> Thanks in advance
>
> Steen


Steen,

It might be something like this - adjust to suit your own requirements by 
changing CSIDL_PERSONAL:

uses
  ShlObj;

var
  PIDL: PItemIDList;
  MyDocumentsDirectory: array [0..MAX_PATH] of char;

begin
  SHGetSpecialFolderLocation (0, CSIDL_PERSONAL, PIDL);
  SHGetPathFromIDList (PIDL, MyDocumentsDirectory);
end;

Cheers,
David

David,

Thank you, I am sure your code will work in far the most cases.

Perhaps I was not clear enough, but I was thinking of a code example doing:

a) Check if OS supports KNOWNFOLDERID values as suggested by Gambit by checking if the function exists.
b) If yes then use KNOWNFOLDERID method else use CSIDL method.



Well, what I excatly need is the CSIDL_COMMON_APPDATA (or KNOWNFOLDERID equivivalent) and then create a subfolder to that.

In XP typically: C:\Documents and Settings\All Users\Application Data\MyFolder



A bit off topic I have a few additional questions (hope they make sence):

1) Any write access problems under Vista here?
2) Can I set that any user should have write access to MyFolder when I create it?
3) Will a Windows service have write acces to the MyFolder?

Steen

<Steen Albrechtsen> wrote in message news:21515@forums.codegear.com...

> Perhaps I was not clear enough, but I was thinking of a code example 
> doing:
>
> a) Check if OS supports KNOWNFOLDERID values as suggested
> by Gambit by checking if the function exists.
> b) If yes then use KNOWNFOLDERID method else use CSIDL method.

Something like the following:

    type
        KNOWNFOLDERID = TGuid;

    const
        FOLDERID_ProgramData: KNOWNFOLDERID = 
'{62AB5D82-FDC1-4DC3-A9DD-070D1D495D97}';

    var
        SHGetKnownFolderPathFunc = function(const rfid: KNOWNFOLDERID; 
dwFlags: DWORD; hToken: THandle; var ppszPath: PWideChar): HResult; stdcall;
        SHGetKnownFolderIDListFunc = function(const rfid: KNOWNFOLDERID; 
dwFlags: DWORD; hToken: THandle; var ppidl: PItemIDList): HResult; stdcall;

    function PathFromIDList(Pidl: PItemIdList): String;
    var
        Path: array[0..MAX_PATH] of Char;
    begin
        if SHGetPathFromIDList(Pidl, Path) then
            Result := Path
        else
            Result := '';
    end;


    function GetCommonAppDataPath: String;
    var
        Path: PWideChar;
        Pidl: PItemIdList;
    begin
        Result := '';
        if @SHGetKnownFolderPathFunc <> nil then
        begin
            if Succeeded(SHGetKnownFolderPathFunc(FOLDERID_ProgramData, 0, 
0, Path) then
            begin
                try
                    Result := Path;
                finally
                    CoTaskMemFree(Path);
                end;
                Exit;
            end;
        end
        else if @SHGetKnownFolderIDListFunc <> nil then
        begin
            if Succeeded(SHGetKnownFolderIDListFunc(FOLDERID_ProgramData, 0, 
0, Pidl) then
            begin
                try
                    Result := PathFromIDList(Pidl);
                finally
                    CoTaskMemFree(Pidl);
                end;
                Exit;
            end;
        end;

        if Succeeded(SHGetFolderLocation(0, CSIDL_COMMON_APPDATA, 0, 0, 
Pidl) then
        try
            Result := PathFromIDList(Pidl);
        finally
            CoTaskMemFree(Pidl);
        end;
    end;

    procedure InitVistaFunctions;
    var
        hShell32: THandle;
    begin
        hShell32 := GetModuleHandle('SHELL32');
        @SHGetKnownFolderPathFunc := GetProcAddress(Shell32, 
'SHGetKnownFolderPath');
        @SHGetKnownFolderIDListFunc := GetProcAddress(Shell32, 
'SHGetKnownFolderIDList');
    end;

    initialization
        InitVistaFunctions;

> 2) Can I set that any user should have write access to MyFolder when I 
> create it?

The Win32 API CreateDirectory/Ex() functions have an lpSecurityAttributes 
parameter for that purpose.  Allocate a SECURITY_ATTRIBUTES record and fill 
it in with details to provide write access to all users.

> 3) Will a Windows service have write acces to the MyFolder?

Yes, provided it runs in a user account that has the proper security rights 
assigned to it.

-- 
Remy Lebeau (TeamB)

Gambit,

Thank you so much! Now I know I am doing things right ;-)

I made it work using D2007 (still waiting to receive my ordered D2009) under XP. Anyone can check under Vista?

Since this is of general interest (can easily be modified/generalised to get any known folder) and a minor change was needed, here is my working unit:

EDIT: NOTE less than and greater than characters dissapear in the code.
EDIT2: Now found out how to display code in a better way (the upper characters are still missing though):

{code}
unit UKNOWNFOLDER;


interface

function GetCommonAppDataPath: String;


implementation

uses
  Windows, ShlObj, ActiveX;

type
  KNOWNFOLDERID = TGuid;

const
  FOLDERID_ProgramData: KNOWNFOLDERID = '{62AB5D82-FDC1-4DC3-A9DD-070D1D495D97}';

var
  SHGetKnownFolderPathFunc: function(const rfid: KNOWNFOLDERID;
  dwFlags: DWORD; hToken: THandle; var ppszPath: PWideChar): HResult; stdcall;
  SHGetKnownFolderIDListFunc: function(const rfid: KNOWNFOLDERID;
  dwFlags: DWORD; hToken: THandle; var ppidl: PItemIDList): HResult; stdcall;

function PathFromIDList(Pidl: PItemIdList): String;
var
  Path: array[0..MAX_PATH] of Char;
begin
  if SHGetPathFromIDList(Pidl, Path) then
    Result := Path
  else
    Result := '';
end;

function GetCommonAppDataPath: String;
var
  Path: PWideChar;
  Pidl: PItemIdList;
begin
  Result := '';
  if @SHGetKnownFolderPathFunc <> nil then
  begin
    if Succeeded(SHGetKnownFolderPathFunc(FOLDERID_ProgramData, 0, 0, Path)) then
    begin
      try
        Result := Path;
      finally
        CoTaskMemFree(Path);
      end;
      Exit;
    end;
  end
  else
    if @SHGetKnownFolderIDListFunc <> nil then
    begin
      if Succeeded(SHGetKnownFolderIDListFunc(FOLDERID_ProgramData, 0, 0, Pidl)) then
      begin
        try
          Result := PathFromIDList(Pidl);
        finally
          CoTaskMemFree(Pidl);
        end;
        Exit;
       end;
    end;

(*  Changed:
  if Succeeded(SHGetFolderLocation(0, CSIDL_COMMON_APPDATA, 0, 0, Pidl)
 To:
*)

  if Succeeded(SHGetSpecialFolderLocation(0, CSIDL_COMMON_APPDATA, Pidl)) then
    try
      Result := PathFromIDList(Pidl);
    finally
      CoTaskMemFree(Pidl);
    end;
end;

procedure InitVistaFunctions;
var
  hShell32: THandle;
begin
  hShell32 := GetModuleHandle('SHELL32');
  @SHGetKnownFolderPathFunc := GetProcAddress(hShell32, 'SHGetKnownFolderPath');
  @SHGetKnownFolderIDListFunc := GetProcAddress(hShell32, 'SHGetKnownFolderIDList');
end;

initialization
  InitVistaFunctions;
end.
{code}


Greetings

Steen

Edited by: Steen Albrechtsen on Sep 26, 2008 3:37 PM

Edited by: Steen Albrechtsen on Sep 27, 2008 6:34 PM

Edited by: Steen Albrechtsen on Sep 27, 2008 6:41 PM

Edited by: Steen Albrechtsen on Sep 27, 2008 6:43 PM