From: Douglas J. Steele on
I'm confused. The FileOpen dialog (such as what's at
http://www.mvps.org/access/api/api0001.htm at "The Access Web") returns the
full path to the file, so what parsing do you need to do?

Are you trying to split the full path into folder and file? Use the InStrRev
function to find the last slash in the path:

strFullPath = ahtCommonFileOpenSave(...)
If Len(strFullPath) > 0 Then
strFileOnly = Mid(strFullPath, InStrRev(strFullPath, "\") + 1)
strPathOnly = Left(strFullPath, InStrRev(strFullPath, "\"))
End If

--
Doug Steele, Microsoft Access MVP
http://www.AccessMVP.com/DJSteele
(no e-mails, please!)

"Dennis" <Dennis(a)discussions.microsoft.com> wrote in message
news:592BA016-1D2B-4DA2-B20E-4DEF73B64487(a)microsoft.com...
> Douglas,
>
> Your Comment: For what it's worth, it really wasn't appropriate to
> hardcode
> "C:\Documents and Settings\<User Name>\My Documents\....." under XP: for
> instance, on my XP machine, my My Documents folder is located on the D
> drive.
>
> My Response: I see you point and I agree. However, after reading your
> response I see where I left out an important piece. I'm still learning
> for
> excuse the faux pas.
>
> I did not "hardcode" my paths. My users create or download their
> documents
> into their directory and then "attach" the documents to their access
> database. I use file FileOpen routine that I found on one of the MVP
> website
> (I forget whose). This routine access the standard windows File Open
> window.
> The user navigates to the directory in which their documents is stores and
> selects the document. The routine returns a path and a file name which I
> then store in my database.
>
> I guess at that point I am going to have to parse the path that is
> returned
> and store it in pieces. This seems to be a pretty "ugly" way to do it. I
> was hopping there is a better way to do this.
>
>
> Dennis


From: Dennis on
Doug,

You are correct, the The FileOpen dialog (at
http://www.mvps.org/access/api/api0001.htm at "The Access Web") returns the
full path to the file.

Returning the full path to the file is the problem! I store the pull path
name in my database and therein lies the problem. This works great until you
upgrade to Vista or Windows 7 and "C:\Documents and Settings\<User Name>\My
Documents\..." no longer exist!


The users started using the software on XP where the full path was
"C:\Documents and Settings\<User Name>\My Documents\....." . The have now
upgraded to Windows 7. Windows 7 moves the data from C:\Doc & Setting\<User
Name>\My Docs..." to "C:\Users\<User Names>\Documents\...". Their existing
data of file paths to documents is no longer valid!

And that is the problem. When upgrading from Xp to Vista or Win 7, I have
to convert the database of file path name. I'm trying to avoid doing having
to convert the data for future users.

Or do I just have to bite the bullent and write a conversion program for
users moving from 2000/Xp to Vista / Win 7?

Thanks,

Dennis
From: Douglas J. Steele on
So you're storing the full path to the file, and now the file doesn't exist
in that location?

Just store the name of the file and derive the location using the API call.
That should work for both current users and future users.

--
Doug Steele, Microsoft Access MVP
http://www.AccessMVP.com/DJSteele
(no e-mails, please!)

"Dennis" <Dennis(a)discussions.microsoft.com> wrote in message
news:9F8558A2-2D56-4E1F-AC4B-E34B4FC506B9(a)microsoft.com...
> Doug,
>
> You are correct, the The FileOpen dialog (at
> http://www.mvps.org/access/api/api0001.htm at "The Access Web") returns
> the
> full path to the file.
>
> Returning the full path to the file is the problem! I store the pull path
> name in my database and therein lies the problem. This works great until
> you
> upgrade to Vista or Windows 7 and "C:\Documents and Settings\<User
> Name>\My
> Documents\..." no longer exist!
>
>
> The users started using the software on XP where the full path was
> "C:\Documents and Settings\<User Name>\My Documents\....." . The have now
> upgraded to Windows 7. Windows 7 moves the data from C:\Doc &
> Setting\<User
> Name>\My Docs..." to "C:\Users\<User Names>\Documents\...". Their
> existing
> data of file paths to documents is no longer valid!
>
> And that is the problem. When upgrading from Xp to Vista or Win 7, I have
> to convert the database of file path name. I'm trying to avoid doing
> having
> to convert the data for future users.
>
> Or do I just have to bite the bullent and write a conversion program for
> users moving from 2000/Xp to Vista / Win 7?
>
> Thanks,
>
> Dennis


From: David W. Fenton on
=?Utf-8?B?RGVubmlz?= <Dennis(a)discussions.microsoft.com> wrote in
news:04B7485C-136D-4800-A4A7-108E6A0CA229(a)microsoft.com:

> Doug,

Actually, it was me, not Doug:

> Your comment: Note that some of the defined folder locations have
> changed writability by non-admins between WinXP and Vista/Win7
> (e.g., \All Users\AppData, previously world writable, now writable
> only by admins, so it's no longer a place to put your front end on
> a machine shared by multiple users -- instead each user has to
> have their own copy, or you have to set permissions manually.
>
> My Response:
> Normally I put my front end in my own directory directly of the
> drive letter. Is that a bad way to do it?

Yes. The root of the system drive is read-only except for
administrators (and possibly other groups, such as Power Users), and
any folders created in it inherit those permissions. You can
manually set permissions to something non-standard, but that
requires human intervention on each individual machine, which means
you can't do it in code (or you have to use an installer program
that can elevate its permissions to do things it can't otherwise
do).

> I've done it this way to avoid the
> multi-use issue. I guess the only issue then is all users have
> access to the app, no just the desired user. But I've only had
> this issue pop up once. But your point is well taken.
>
> What is your advice for where to place the front end software?

In the user's profile, one copy for each user of the machine.
There's no disk space issue any longer, so it's a waste of time to
be worrying about multiple copies of the front end on the same
machine, one for each user logon.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Dennis on
Douglas,

Your comments:
So you're storing the full path to the file, and now the file doesn't exist
in that location?

Just store the name of the file and derive the location using the API call.
That should work for both current users and future users.


Response:
First let me apologize for not having all of the information in the first
question. The truth is I had not though about all of the different senarios
that your response is making me think of now.

No, that will not work either. I just found out today that some of the
users are NOT storing their documents in Windows' "My Document" directories.
Some of my users are storing their documents in their own directory structure
completely outside of "My Documents". They are using directory structures
such as C:\Customer\<CustName>\....". The documents that are scanned in goto
"C:\Scan\<scan date>\...". And in stead of the C drive, the data might be on
the network. Using the derived locations will not help in these case.

That is why I figure I will have to parse the path name. If it is the XP or
Vista "MY Doc" structure, then I will have to figure out a way to store that
information. If it is not part of the "MY Doc" structure, then I will have
to store the full path name.

Also, I have to figure out if I want to store the network drive leter (which
I don't think I want to as different computer could have the same drive
letters pointing to different directories, which the should not but who
knows).

Ahhhh, the more I think about it the uglier it gets.

From Access, can I tell if a drive is local or a network drive?
If I can tell, can I get the true name path (DNS path? - sorry don't know
the correct techincal term) - ie. U: really is "\\SBS2003\share"

Again, my apoligize for not having thought this all the way through.
Unless someone else brings up another angle I have not though about, I think
I have provided all of the information you might need. But then again, watch
me be proven wrong.

Thanks for you assitance.

Dennis