Vista - Extracting drive, path, filebasename WITH string functions and NOT system function ???

Recently I asked here for functions to extract the individual
parts (drive, path, filebase and extension) from a string like:

myfile="D:\aaa\bbb\ccc\ddd.txt"

I was told to use built-in functions like:

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.GetFile(strFile)
Set objFolder = objFile.ParentFolder
Wscript.Echo "Filename : " & objFile.Name
Wscript.Echo "Path : " & objFile.ParentFolder

But the big disadvantage here is that the file MUST exist.

But what if the filenamestring is passed as parameter and tells which log file should be created
(in the future). At the moment of processing the logfile does not exist yet.

So all the built-in funtion don't work and I get an error.

I must use some string manipulation functions like:

Wscript.Echo "Path : " & Left(strFile, InstrRev(strFile, "\"))

But how can I extract similarly filebase name ("ddd"), extension ("txt"),
filename ("ddd.txt") and drive ("D:") with string search and copy functions?

Thomas

"Thomas Lebrecht" <t.lebrecht@xxxxxx> wrote in message
news:49d328f1$0$30236$9b4e6d93@xxxxxx-online.net...To extract the file name, use the "mid" function in order to extract all
characters after the right-most backslash. InstrRev(strFile, "\") will help
you locate it.

To extract the file extension, use the "mid" function in order to extract
all characters after the right-most full stop. InstrRev(strFile, ".") will
help you locate it.

Thomas Lebrecht wrote:Paul Randall's reply to your original post explained that the
FileSystemObject object has methods to parse a string to extract the
information. You really should download the scripting help file
(script56.chm) if it's not already on your system.

Set objFSO = CreateObject("Scripting.FileSystemObject")
Wscript.Echo "Filename : " & objFSO.GetFileName(myfile)
Wscript.Echo "Path : " & objFSO.GetParentFolderName(myfile)
Wscript.Echo "File basename : " & objFSO.GetBaseName(myfile)
Wscript.Echo "Extension : " & objFSO.GetExtensionName(myfile)
Wscript.Echo "Drive : " & objFSO.GetDriveName(myfile)

As the documentation says: (Honestly, install the docs!) the methods
work only on the provided path string. They do not attempt to resolve
the path, nor check for the existence of the specified path.

--
Steve

When a man wants to murder a tiger he calls it sport; when the tiger
wants to murder him he calls it ferocity. -George Bernard Shaw

"Steve" <cerberus40@xxxxxx> wrote in message
news:eRg268qsJHA.5912@xxxxxxIf the file in question does not exist then the OP will not be able to
create an object based on the file name. As he correctly says, this will
prevent him from extracting the various file name components using FSO
methods. He must use string manipulation techniques, as he suspected.

"Thomas Lebrecht" <t.lebrecht@xxxxxx> schriebRecently I told you, NOT to post vbscript questions to the VB.net group. I
tell you again, now.


Armin

"Armin Zingler" <az.nospam@xxxxxx> wrote in message
news:Od0T0grsJHA.3928@xxxxxx
Why not? It's got "vb" in its name, so it's fair game ;-) At least that's
what the various dotnet evangelists such as the idiot McCarthy tell us when
we ask people not to post vb.net questions to the class Visual Basic group!

Mike

On Apr 1, 5:57*am, "Pegasus [MVP]" <n...@xxxxxx> wrote:I believe you're assertion is incorrect. No file needs to exist to
use FSO to *parse strings* that look like file paths. (Which is what
the OP states is his objective.) Because the path does not exist does
not limit the ability to parse it. IMHO, the practicalities of using
the parsed information is another issue, entirely. The trick, as
Steve's examples illustrate, is to use the appropriate FSO parsing
methods, as opposed to trying to access the non-existent file's
properties. There is a difference.

Tom Lavedas
***********
http://there.is.no.more/tglbatch/

"T Lavedas" <tglbatch@xxxxxx> wrote in message
news:ea0c50b8-6fae-456a-adb8-f009c77b5f94@xxxxxx
On Apr 1, 5:57 am, "Pegasus [MVP]" <n...@xxxxxx> wrote:I believe you're assertion is incorrect. No file needs to exist to
use FSO to *parse strings* that look like file paths. (Which is what
the OP states is his objective.) Because the path does not exist does
not limit the ability to parse it. IMHO, the practicalities of using
the parsed information is another issue, entirely. The trick, as
Steve's examples illustrate, is to use the appropriate FSO parsing
methods, as opposed to trying to access the non-existent file's
properties. There is a difference.

Tom Lavedas
***********
http://there.is.no.more/tglbatch/
==================
Sounds good but how exactly would you do it? The following script fails as
expected:
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oFile = oFSO.GetFile("c:\SomePath\Some File.txt")
WScript.Echo oFile.Path, oFile.Name, oFile.Type

And how would you get the file extension as opposed to the file type?

"Thomas Lebrecht" <t.lebrecht@xxxxxx> wrote in message
news:49d328f1$0$30236$9b4e6d93@xxxxxx-online.net...Hi, Thomas
As I said in my previous post, the names of the FSO path parsing methods
start with GET and end with NAME. These methods take strings as arguments
and return strings as results. The FSO does not care whether the path
actually exists.

GetAbsolutePathName
GetBaseName
GetDriveName
GetExtensionName
GetFileName
GetParentFolderName

The FSO path-parsing methods are also happy to parse strings that are
similar to file paths, such as URLs. In my experience, it treats forward
and back slashes the same.

-Paul Randall

"Pegasus [MVP]" <news@xxxxxx> wrote in message
news:%23ZHAYDusJHA.1212@xxxxxxDon't GetFile; GetFileName

-Paul Randall