🚀 go-pugleaf

"JB" <jo4508@yahoo.co.uk> wrote in message
news:4656efa1$1@newsgroups.borland.com...

> I have tried using the parameter CSIDL_MYDOCUMENTS but
> on a standalone PC it gives a pidl of null.

Then something is wrong, because it shouldn't be returning a NULL
pidl.  Please show your actual code.


Gambit

>Then something is wrong, because it shouldn't be returning a NULL
>pidl.  Please show your actual code.

AnsiString Pathname;
LPITEMIDLIST pidlDocFiles; 
char Buf[MAX_PATH];

  if (SHGetFolderLocation(NULL, CSIDL_MYDOCUMENTS, NULL, 0, &pidlDocFiles) != S_FALSE)
  {
      SHGetPathFromIDList(pidlDocFiles, Buf);
      Pathname = AnsiString(Buf);
  }


The above gives null in pidlDocFiles, whilst replacing 
CSIDL_MYDOCUMENTS with CSIDL_PERSONAL gives a valid value 
which is translated by SHGETPathFromIDList to the correct path.

JB

JB wrote:

>I need to get the pathname for the user's My Documents folder.
>Initially I used SHGetFolderLocation, with CSIDL_PERSONAL this
>works ok until the user is logged onto a network and it returns 
>a location on the server that is a personal folder set up for 
>the user.
>I have tried using the parameter CSIDL_MYDOCUMENTS but on a 
>standalone PC it gives a pidl of null.
>What is the best way to get the location of the My Documents 
>folder on the hard drive of the PC?

From the help:
<help>
Once your application has the My Documents PIDL, it can handle the
folder just as it would a normal file system folder: enumerating
items, parsing, binding, and performing any other valid folder
operations. The Shell automatically maps changes in My Documents or
its subfolders to the appropriate file system folders.

If your application needs access to the actual file system folder that
contains the current user's documents, pass CSIDL_PERSONAL to
SHGetFolderLocation. The function returns the PIDL of the file system
folder that is displayed in the current user's My Documents folder.
</help>

From this it sounds like you can use the MyDoc PIDL for shell
operations, but if you want to use "normal" file functions, you need
to use Personal.

I don't think that there is any guarantee that MyDocuments physically
exists on the local machine.  It would be so much easier to
backup/enforce retention rules if all documents existed on the server.

"JB" <jo4508@yahoo.co.uk> wrote in message
news:46571711@newsgroups.borland.com...

>   if (SHGetFolderLocation(NULL, CSIDL_MYDOCUMENTS

CLSID_MYDOCUMENT is only recognized on XP and higher.  It is
equivilent to CLSID_PERSONAL, which is recognized on all versions.

> != S_FALSE

That is the wrong way to check for errors. Anything other than S_OK is
an error.  You should use the SUCCEEDED() macro instead:

    AnsiString Pathname;
    LPITEMIDLIST pidlDocFiles = NULL;

    HRESULT hRes = SHGetFolderLocation(NULL, CSIDL_MYDOCUMENTS, NULL,
0, &pidlDocFiles);
    if( FAILED(hRes) )
        hRes = SHGetFolderLocation(NULL, CSIDL_PERSONAL, NULL, 0,
&pidlDocFiles);

    if( SUCCEEDED(hRes) )
    {
        char Buf[MAX_PATH+1] = {0};
        SHGetPathFromIDList(pidlDocFiles, Buf);
        CoTaskMemFree(pidlDocFiles);
        Pathname = Buf;
    }


Gambit

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>CLSID_MYDOCUMENT is only recognized on XP and higher.  It is
>equivilent to CLSID_PERSONAL, which is recognized on all versions.

CSDIL_MYDOCUMENTS is definitely not working on XP or 2000, 
whereas CSDIL_PERSONAL is working on both.
I have used both the IDE and a MessageBox to see what value I 
get.

>> != S_FALSE
>
>That is the wrong way to check for errors. Anything other than S_OK is
>an error.  You should use the SUCCEEDED() macro instead:

Thanks - will change this.

I still have the problem that I cannot be sure to get the My 
Documents on a local drive, I do not want to (possibly) use a 
server location. What is the best option to use to find a 
location for the user data to be stored? Should I use Local 
Settings\Application Data ?

Thanks,
JB

Bob Gonder <notbg@notmindspring.invalid> wrote:
>From the help:
><help>
>Once your application has the My Documents PIDL, ......
>From this it sounds like you can use the MyDoc PIDL for shell
>operations, but if you want to use "normal" file functions, you need to use Personal.
>
>I don't think that there is any guarantee that MyDocuments >physically exists on the local machine.  It would be so much >easier to backup/enforce retention rules if all documents >existed on the server.

I read all the help - unfortunately it does not help me. I am finding that CSDIL_MYDOCUMENTS is not returning anything even when I specifically know there is a My Documents on the local drive on an XP machine!
JB

On 25 May 2007 07:16:01 -0700, "JB" <jo4508@yahoo.co.uk> wrote:

>CSIDL_MYDOCUMENTS

This identifier works only for ComCtl32.dll version 6 and greater -
meaning Windows XP/Windows 2003/Vista. But in order for a program to
use that version of library you must also add manifest that indicates
that version 6 should be used if available.

"JB" <jo4508@yahoo.co.uk> wrote in message
news:4658757e$1@newsgroups.borland.com...

> CSDIL_MYDOCUMENTS is definitely not working on XP or 2000

According to MSDN, CSIDL_MYDOCUMENTS is supported on XP.  Or more
accurately, is recognized by shell32.dll v6.0 and higher, which began
shipping in XP.

> whereas CSDIL_PERSONAL is working on both.

As I would expect it to, and is what MSDN also says.

> I still have the problem that I cannot be sure to get the
> My Documents on a local drive

Yes, you can.

> What is the best option to use to find a location for the user data
> to be stored? Should I use Local Settings\Application Data ?

That is what you are supposed to use, yes.  Please read MSDN for more
details:

    How to write a Windows XP Application that stores user and
application data in the correct location
    http://support.microsoft.com/kb/310294

Refer to the "Classify Application Data" and "Store Application Data
in the Correct Location" sections.

Also:

    Application Specification for Microsoft Windows 2000 for Desktop
Applications
    Chapter 4: Data and Settings Management
    http://msdn2.microsoft.com/en-us/library/ms995853.aspx

Also:

    What's the difference between My Documents and Application Data?
    https://blogs.msdn.com/oldnewthing/archive/2005/07/01/434647.aspx


Gambit

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>That is what you are supposed to use, yes.  Please read MSDN for more details:
>
>    http://support.microsoft.com/kb/310294
>    Chapter 4: Data and Settings Management
>    http://msdn2.microsoft.com/en-us/library/ms995853.aspx
>https://blogs.msdn.com/oldnewthing/archive/2005/07/01/434647.aspx

Many thanks, I have previously browsed MSDN, but these links 
look useful, I will read them in detail.

Perhaps you can give me your view on this:-
As mentioned, my application needs to store data, the nature 
of the data is that it is created by the application according 
to information that the user enters into the application. The 
data file can only be read by my application and it is not 
intended that the user know about the details of the data 
being stored or be able to access the file to copy it, email 
etc. They do not get a choice of what to call it or where to 
write it.  I do however allow the user to backup and restore 
the data file.
I am not entirely clear as to whether this is therefore a user 
file or an application file.  I am coming to the point of view 
that it is an application file and I should store it in Local 
Settings\Application Data.  Then when allowing the user to 
backup the file, I should default to My Documents as the 
location. Would this be acceptable?
Thanks,
JB

"JB" <jo4508@yahoo.co.uk> wrote in message
news:465a8313$1@newsgroups.borland.com...

> I am not entirely clear as to whether this is therefore a
> user file or an application file.

It is an application file.  You app's code, not the user, is creating
and maintaining the file.  So you should be storing it in one of the
available "Application Data" folders.


Gambit