IndexOutOfRange error when calling SHGetSpecialFolderPath

[Neville Lang]

Hi all,

Within my .NET CF app on a PPC, I need to obtain folder path strings in the
language the Pocket PC's operating system is set for. Using C#, I call the
operating system function SHGetSpecialFolderPath via P/Invoke.

While calling this function works for some CSIDL values, there are others
that are giving me the "IndexOutOfRange" error. Here is a code snippet:

using ...
....
....

public class MyClass
{
public const uint CSIDL_WINDOWS = 0x24;
public const uint CSIDL_FONTS = 0x14;
public const uint CSIDL_STARTMENU = 0x0B;

[DllImport("coredll.dll", SetLastError=true)]
public static extern int SHGetSpecialFolderPath(int hwndOwner,
StringBuilder lpszPath, uint nFolder, int fCreate);


public MyClass() // Constructor
{
StringBuilder sb = new StringBuilder();
SHGetSpecialFolderPath(0, sb, CSIDL_WINDOWS, 0);
string sPath = sb.ToString(); // This one is OK

sb = new StringBuilder();
SHGetSpecialFolderPath(0, sb, CSIDL_FONTS, 0);
sPath = sb.ToString(); // This one is OK

sb = new StringBuilder();
SHGetSpecialFolderPath(0, sb, CSIDL_STARTMENU, 0); // This line
returns the IndexOutOfRange error when debugging
sPath = sb.ToString(); // This one is NOT OK
}
}


I also found that I get the same IndexOutOfRange error if the CSIDL value is
0x02, 0x06 and 0x16. Can anyone shed some light on why calling this function
with these values fails under C# while some of the others are OK?

A Google scan did find some code in VB .NET that claims to not fail so why
it is failing under C#.

Regards,
Neville Lang

 

[Peter Foot [MVP]]

In the EnvironmentEx code I created a StringBuilder pre-sized to fit the
maximum path length (currently 255 chars) plus trailing null, you can view
the code (C#) online here:-
http://www.opennetcf.org/sourcebrow...Pub/wwwroot/Source/OpenNETCF/EnvironmentEx.cs

This should work successfully with all of the csidls, and has been tested on
Smartphone, Pocket PC and CE.NET (some platforms don't support some of the
folders)

Peter

 

[Neville Lang]

Peter,

Thanks for your information - it now works. It is now obvious the problem
was in pre-setting the size of StringBuilder and not just using the default.

Regards,
Neville Lang

In the EnvironmentEx code I created a StringBuilder pre-sized to fit the
maximum path length (currently 255 chars) plus trailing null, you can view
the code (C#) online here:-
http://www.opennetcf.org/sourcebrow...Pub/wwwroot/Source/OpenNETCF/EnvironmentEx.cs

This should work successfully with all of the csidls, and has been tested on
Smartphone, Pocket PC and CE.NET (some platforms don't support some of the
folders)

Peter

--
Peter Foot
Windows Embedded MVP
www.inthehand.com

Hi all,

Within my .NET CF app on a PPC, I need to obtain folder path strings in
the
language the Pocket PC's operating system is set for. Using C#, I call the
operating system function SHGetSpecialFolderPath via P/Invoke.

While calling this function works for some CSIDL values, there are others
that are giving me the "IndexOutOfRange" error. Here is a code snippet:

using ...
...
...

public class MyClass
{
public const uint CSIDL_WINDOWS = 0x24;
public const uint CSIDL_FONTS = 0x14;
public const uint CSIDL_STARTMENU = 0x0B;

[DllImport("coredll.dll", SetLastError=true)]
public static extern int SHGetSpecialFolderPath(int hwndOwner,
StringBuilder lpszPath, uint nFolder, int fCreate);


public MyClass() // Constructor
{
StringBuilder sb = new StringBuilder();
SHGetSpecialFolderPath(0, sb, CSIDL_WINDOWS, 0);
string sPath = sb.ToString(); // This one is OK

sb = new StringBuilder();
SHGetSpecialFolderPath(0, sb, CSIDL_FONTS, 0);
sPath = sb.ToString(); // This one is OK

sb = new StringBuilder();
SHGetSpecialFolderPath(0, sb, CSIDL_STARTMENU, 0); // This line
returns the IndexOutOfRange error when debugging
sPath = sb.ToString(); // This one is NOT OK
}
}


I also found that I get the same IndexOutOfRange error if the CSIDL value
is
0x02, 0x06 and 0x16. Can anyone shed some light on why calling this
function
with these values fails under C# while some of the others are OK?

A Google scan did find some code in VB .NET that claims to not fail so why
it is failing under C#.

Regards,
Neville Lang