Folks

I have a string which must contain just a file name,  a sub folder and
file name or a complath path and file name.  So what's the best means
of validating it?   This file could be in the same path as the VB6
EXE.

The simplest approach would be to see if it starts with a \\ or x:
where x is A-Z.   If so then it's a path and file name.

Otherwise it's a relative path and file name so insert the App.Path in
front.

Am I missing something?  

Tony

Another possibility is a drive/server+share specification with a file name
without a diretcory path, e.g. C:autoexec.bat. In this case you have to
remove the drive specification from App.Path and insert the remaining
directory path between drive/server+share specification.

But why App.Path? If a relative path is given, usually it is not relative
to the application directory but to the current directory of the
application (curdir$).

My approach to this would be as follows:
1. Check, if the given relative or absolute path points to an existing file
(GetFileAttributes() etc.)
2. Get the absolute file path by calling GetFullPathName() of the Windows
API.

Step 1 is necessary since on some version of windows GetFullPathName()
sometimes returns curious results if the file does not exist....

Other usefull procedures for validating, etc. a path can be found in
SHLWAPI.DLL (e.g. PathIsRelative()).

--
Thorsten Albers

albers (a) uni-freiburg.de

To be sure I understand, you want to be sure it's a "valid" filename?  
Not necessarily that it exists?

This function will tell you whether the path is relative or absolute,
if that's what you're wanting:

   Private Declare Function PathIsRelativeW Lib "shlwapi" (ByVal
lpszPath As Long) As Boolean

   Public Function PathIsRelative(ByVal Path As String) As Boolean
      ' Searches a path and determines if it is relative.
      PathIsRelative = PathIsRelativeW(StrPtr(Path))
   End Function

And this is my favorite way to build paths, now:

   Private Declare Function PathCombineW Lib "shlwapi" (ByVal lpszDest
As Long, ByVal lpszDir As Long, ByVal lpszFile As Long) As Boolean

   Public Function PathCombine(ByVal Directory As String, ByVal File As
String) As String
      Dim Buffer As String
      ' Concatenates two strings that represent properly formed
      ' paths into one path, as well as any relative path pieces.
      Buffer = String$(MAX_PATH, 0)
      If PathCombineW(StrPtr(Buffer), StrPtr(Directory), StrPtr(File))
Then
         PathCombine = TrimNull(Buffer)
      End If
   End Function

PathCombine means you don't have to worry about backslashes anymore.

(Requires Win98/2000 or IE4 or higher.)

--
.NET: It's About Trust!  http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org

It occurs to me you may want to do more than just realize whether the
path is relative or not.  Here's a function that will fully qualify a
relative path based on the working directory:

   Private Declare Function PathSearchAndQualifyW Lib "shlwapi" (ByVal
lpszPath As Long, ByVal lpszFullyQualifiedPath As Long, ByVal
cchFullyQualifiedPath As Long) As Boolean

   Public Function PathQualify(ByVal Path As String) As String
      Dim Buffer As String
      ' Returns True if the path is correctly formatted and
      ' fully qualified. If the path name doesn't contain
      ' folder info, the name of the active directory is used
      ' to create a qualified path.
      Buffer = String$(MAX_PATH, 0)
      If PathSearchAndQualifyW(StrPtr(Path), StrPtr(Buffer), MAX_PATH)
Then
         PathQualify = TrimNull(Buffer)
      End If
   End Function

I realize that may not be what you want, because you seem to have an
anchor at App.Path, but just in case?

--
.NET: It's About Trust!  http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org

Yes, the file must exist.  

Yup, that's fine.   Although a few years ago I did get a report of a
bug in A2.0 which dates from 1994 and a few years before that a bug
with NT 4.0.

Tony

On Fri, 11 Jun 2010 22:37:55 +0000 (UTC), "Thorsten Albers"

Hmm, I'd have to understand the current directory a bit more then.
But I don't htink I want or need it.

My utility is a drag and drop deploy onto a file server used by Access
developer/programmers.   The MDB file in questoin will be included in
the zip file which will be distributed along with the VB6 exe.   So
it's quite likely that the flie will be thrown into the same folder
along with the VB6 exe and various dev created INI files.

Now what is also very likely to happen is that users have read only
access to the utilityfolder however they must have read/write/etc
permission to the folder which contains this particular file.
(Actually an Access MDB and the associated LDB file which Jet/DAO will
created and delete as required.)  So it is quite likely that the
dev/pgmr will need to create another folder, which could be a
subfolder, for the users to access the MDB file.

Thus my somewhat unusual configuration.

Tony

Tony Toews wrote :

In that case, I'd just test for existence first, then pass it to that
PathQualify function I already posted.

You could also do something like:

  If FileExists(FileName) Then
    FileName = PathQualify(FileName)
  ElseIf FileExists(PathCombine(App.Path, FileName)) Then
    FileName = PathQualify(PathCombine(App.Path, FileName))
  Else
    ' Bad juju
  End If

The first test assumes the filespec is relative to the curdir, the
second assumes it's relative to the app.path.

And almost always NT4 got updated to include IE4 or higher before it
was frozen in time.

Tony Toews wrote :

In that case, I'd just test for existence first, then pass it to that
PathQualify function I already posted.

You could also do something like:

  If FileExists(FileName) Then
    FileName = PathQualify(FileName)
  ElseIf FileExists(PathCombine(App.Path, FileName)) Then
    FileName = PathQualify(PathCombine(App.Path, FileName))
  Else
    ' Bad juju
  End If

The first test assumes the filespec is relative to the curdir, the
second assumes it's relative to the app.path.

And almost always NT4 got updated to include IE4 or higher before it
was frozen in time.

What's with the double posts?  I've seen 3 or 4 from you already....

LFS

Larry Serflaten explained :

It's the only flaw I've found in my new newsreader.  :-(

Sometimes, it just seems to get hung up on a post.  I dunno if the
server's taking too long to acknowledge it, or what.  And then,
apparently, it sends it again.

OE used to do this on occassion, too.  Probably about half or a third
as often, though.

Thank goodness Microsoft is dumping newsgroups and moving us to forums where
there never is such problems.<g>

--
Rick (MVP - Excel)

I thought it was an Escape sequence, meaning to take the first post
literally.

-ralph
<g>

On Fri, 11 Jun 2010 21:55:54 -0400, "Rick Rothstein"

Ha!

Tony

I-m not sure this should be meant as a sincere  <g>.
I mean, it would be valuable if capacities like you and Larry, and other
long term vb6 experienced, joined Carl on the forum. Never mind, we all
know what ever we does wouldn't help. They got to get rid of all the
"spam" on the ms-newsserver one way or the other.
Yet, it's already proved that it's a tremendous advantage having the vb6
gurus
included on the forums. If not an acceptance of including vb6 could be the
resultance of a massive joining, then at least, the petition would looks
more
powerfull.
Of course, it's wisest to keep out of trouble. But not necessarily ......
- if you understand.
/se

It's Karl, not Carl...cenn

--
Customer Hatred Knows No Bounds at MSFT
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

Bawwk!  Paulie want a dingleball, bawwk!

:


: > Thank goodness Microsoft is dumping newsgroups and moving us to forums
: > where there never is such problems.<g>
: >
: > --
: > Rick (MVP - Excel)
: >
: >
:
: I-m not sure this should be meant as a sincere  <g>.
: I mean, it would be valuable if capacities like you and Larry, and other
: long term vb6 experienced, joined Carl on the forum. Never mind, we all
: know what ever we does wouldn't help. They got to get rid of all the
: "spam" on the ms-newsserver one way or the other.
: Yet, it's already proved that it's a tremendous advantage having the vb6
: gurus
: included on the forums. If not an acceptance of including vb6 could be the
: resultance of a massive joining, then at least, the petition would looks
: more
: powerfull.
: Of course, it's wisest to keep out of trouble. But not necessarily ......
: - if you understand.
: /se
:
:
:
: