Board index » delphi » Long to Short filenames and vice versa

Long to Short filenames and vice versa

Anybody know the easiest way to convert long to short filenames and
vice versa?

 

Re:Long to Short filenames and vice versa


Quote
Jason Roberts wrote:

> Anybody know the easiest way to convert long to short filenames and
> vice versa?

        There's an API function that converts a long filename to a
short name - it's GetShortName or something like that. There's no
such function in the other direction.

        What you can do is use FindFirst with either version of the
filename; it will give a match regardless, and then you can look at
the TSearchRec for the other version of the filename. (Note you now
need to follow this with FindClose - I believe this requirement is
new (at least I hope it is because that's my excuse for leaving it
out the first time I mentioned this to someone...))

--
David Ullrich
Sig file accidentally deleted - sorry.

Re:Long to Short filenames and vice versa


Quote
Jason Roberts <jas...@planet.net.au> wrote:
>Anybody know the easiest way to convert long to short filenames and
>vice versa?

The Win32 funcitons GetShortPathName() and GetFullPathName().

Re:Long to Short filenames and vice versa


Quote
Chris Lincoln wrote:

> Jason Roberts <jas...@planet.net.au> wrote:

> >Anybody know the easiest way to convert long to short filenames and
> >vice versa?

> The Win32 funcitons GetShortPathName() and GetFullPathName().

        Huh. Didn't know about GetFullPathName. The docs seem to
indicate that you can use it to convert a short name to a long name
but so far I can't get that to work - have you got an example
handy?

--
David Ullrich
Sig file accidentally deleted - sorry.

Re:Long to Short filenames and vice versa


In article <31C05E99.7...@math.okstate.edu>, David Ullrich
<ullr...@math.okstate.edu> writes

Quote
>Chris Lincoln wrote:

>> Jason Roberts <jas...@planet.net.au> wrote:

>> >Anybody know the easiest way to convert long to short filenames and
>> >vice versa?

>> The Win32 funcitons GetShortPathName() and GetFullPathName().

>       Huh. Didn't know about GetFullPathName. The docs seem to
>indicate that you can use it to convert a short name to a long name
>but so far I can't get that to work - have you got an example
>handy?

Have you given it a *full* path to go on. It won't convert just a
filename on its own unless (possibly) that file happens to be in the
current directory. I fell foul of that yesterday ...
--
Julian Moss                                      J M Technical Services
{*word*19}ermouth, Cumbria, UK                 Technical Writing and Software
(+44) 1900 826514                              jm...@jmtech.demon.co.uk
    Member of the Telework, Telecottage and Telecentre Association

Re:Long to Short filenames and vice versa


Quote
David Ullrich <ullr...@math.okstate.edu> wrote:
>Chris Lincoln wrote:

>> Jason Roberts <jas...@planet.net.au> wrote:

>> >Anybody know the easiest way to convert long to short filenames and
>> >vice versa?

>> The Win32 funcitons GetShortPathName() and GetFullPathName().
>    Huh. Didn't know about GetFullPathName. The docs seem to
>indicate that you can use it to convert a short name to a long name
>but so far I can't get that to work - have you got an example
>handy?

Sorry, I haven't tried using GetFullPathName().  The FilePart
parameter description fooled me into thinking that it would work...

Re:Long to Short filenames and vice versa


Quote
Julian Moss wrote:

> In article <31C05E99.7...@math.okstate.edu>, David Ullrich
> <ullr...@math.okstate.edu> writes
> >Chris Lincoln wrote:

> >> Jason Roberts <jas...@planet.net.au> wrote:

> >> >Anybody know the easiest way to convert long to short filenames and
> >> >vice versa?

> >> The Win32 funcitons GetShortPathName() and GetFullPathName().

> >       Huh. Didn't know about GetFullPathName. The docs seem to
> >indicate that you can use it to convert a short name to a long name
> >but so far I can't get that to work - have you got an example
> >handy?

> Have you given it a *full* path to go on. It won't convert just a
> filename on its own unless (possibly) that file happens to be in the
> current directory. I fell foul of that yesterday ...

        Yes, I gave it a full path. I have c:\deldemos\alongfilename.txt,
and I've tried giving it c:\deldemos\alongf~1.txt for the filename, I also
tried alongf~1.txt for the filename and c:\deldemos for the path, etc -
I can't get it to spit out "alongfilename". Not that it matters since
I can get the long name from FindFirst, but yes I've tried all sorts
of combinations. Evidently I'm doing it wrong, but I can't figure out
what the right way is (hint).

        (Of course it needs the full path - there's no algorithm for
expanding the name, the most it can do is give the long filename of the
file that actually exists on disc...)

--
David Ullrich
Sig file accidentally deleted - sorry.

Re:Long to Short filenames and vice versa


Quote
Chris Lincoln wrote:

> David Ullrich <ullr...@math.okstate.edu> wrote:

> >Chris Lincoln wrote:

> >> Jason Roberts <jas...@planet.net.au> wrote:

> >> >Anybody know the easiest way to convert long to short filenames and
> >> >vice versa?

> >> The Win32 funcitons GetShortPathName() and GetFullPathName().

> >       Huh. Didn't know about GetFullPathName. The docs seem to
> >indicate that you can use it to convert a short name to a long name
> >but so far I can't get that to work - have you got an example
> >handy?

> Sorry, I haven't tried using GetFullPathName().  The FilePart
> parameter description fooled me into thinking that it would work...

        Yeah. I read the docs on GetFullPathname again. It says something
about using the long name "if available", but it also says something about
how it does not check the disc to see if the file actually exists.
        If it doesn't check to see whether the file actually exists then
it's simply impossible for it to be usable to convert short names to long:
How could it possibly know whether alongf~1.txt was short for
alongfilename.txt or alongfffffilename.txt?

        Of course this raises the question exactly what it does do - it's
hard to believe it's nothing but a glorified StrCat, but I don't see how to
get it to convert a short name to a long one and if the docs are right then
it can't possibly do that. (The "API Bible" says the same thing as the
docs here, BTW.) Unless someone has actual code showing me how it
works I'm going to tend to believe that there's no API function for doing
this conversion specifically, (but note you _can_ do it via the Delphi
FindFirst or the API FindFirstFile (uh, like I said - I actually tried
it before claiming it worked.))

        Maybe GetFullPathName _is_ just a StrCat except it's smart enough
to do the same thing with "c:\deldemos" and "c:\deldemos\" ?

--
David Ullrich
Sig file accidentally deleted - sorry.

Re:Long to Short filenames and vice versa


On Sat, 15 Jun 1996 14:54:08 -0500, David Ullrich

Quote
<ullr...@math.okstate.edu> wrote:
>    Yeah. I read the docs on GetFullPathname again. It says something
>about using the long name "if available", but it also says something about
>how it does not check the disc to see if the file actually exists.
>    If it doesn't check to see whether the file actually exists then
>it's simply impossible for it to be usable to convert short names to long:
>How could it possibly know whether alongf~1.txt was short for
>alongfilename.txt or alongfffffilename.txt?

GetFullPathName expands the directory name, but not the file name.
That's why it works with files that do not exist.

For reasons unknown to me, there does not seem to be a GetLongFileName
function, even though the DOS INT 21H function is defined for it.

To compensate for this omission, I threw together a GetLongName
function. It takes a file name as an argument and returns a file name,
expanding directories as needed. The returned string is the long name
that was specified by the user. Thus, if the file name is
"LongFileName.txt", and you pass in "longfilename.txt", then the
returned string is 'LongFileName.txt'.

You can find it in the wnstuf11.zip file at
http://www.tempest-sw.com/freeware/.

For the truly curious and {*word*37}ic, below is a description of how
the function works:

All that is required is to call the $7160 DOS function, passing 2 in
CL, as documented in the Programmer's Guide to Windows 95. Windows 95
implements INT 21 calls in the VWIN32 VxD. The undocumented kernel32
call, VxDCall, calls into this and other VxDs. Thus, GetLongName,
calls sets up the necessary registers, and then calls VxDCall.

I'm sure there's an easier way, but this was highly instructive and
very interesting. I don't guarantee the results, but everyone is
welcome to try GetLongName for themselves.
--
Ray Lischner                              li...@tempest-sw.com
Tempest Software, Corvallis, Oregon, USA  http://www.tempest-sw.com

Re:Long to Short filenames and vice versa


On Sun, 16 Jun 1996 21:55:32 GMT, li...@tempest-sw.com (Ray Lischner)
wrote:

Quote
>All that is required is to call the $7160 DOS function, passing 2 in
>CL, as documented in the Programmer's Guide to Windows 95. Windows 95
>implements INT 21 calls in the VWIN32 VxD. The undocumented kernel32
>call, VxDCall, calls into this and other VxDs. Thus, GetLongName,
>calls sets up the necessary registers, and then calls VxDCall.

>I'm sure there's an easier way, but this was highly instructive and
>very interesting. I don't guarantee the results, but everyone is
>welcome to try GetLongName for themselves.

Another way is to use FindFirst, since it returns both long and short
versions of the filename.  However, doing it that way means you need
to watch out for users who inadvertantly put wildcards in their names.
I think the INT 21 method would return an error in that case.

Duncan Murdoch

Re:Long to Short filenames and vice versa


Quote
Ray Lischner wrote:

> On Sat, 15 Jun 1996 14:54:08 -0500, David Ullrich
> <ullr...@math.okstate.edu> wrote:

> >       Yeah. I read the docs on GetFullPathname again. It says something
> >about using the long name "if available", but it also says something about
> >how it does not check the disc to see if the file actually exists.
> >       If it doesn't check to see whether the file actually exists then
> >it's simply impossible for it to be usable to convert short names to long:
> >How could it possibly know whether alongf~1.txt was short for
> >alongfilename.txt or alongfffffilename.txt?

> GetFullPathName expands the directory name, but not the file name.
> That's why it works with files that do not exist.

> For reasons unknown to me, there does not seem to be a GetLongFileName
> function, even though the DOS INT 21H function is defined for it.

> To compensate for this omission, I threw together a GetLongName
> function. It takes a file name as an argument and returns a file name,
> expanding directories as needed. The returned string is the long name
> that was specified by the user. Thus, if the file name is
> "LongFileName.txt", and you pass in "longfilename.txt", then the
> returned string is 'LongFileName.txt'.

> You can find it in the wnstuf11.zip file at
> http://www.tempest-sw.com/freeware/

> For the truly curious and {*word*37}ic, below is a description of how
> the function works:

> All that is required is to call the $7160 DOS function, passing 2 in
> CL, as documented in the Programmer's Guide to Windows 95. Windows 95
> implements INT 21 calls in the VWIN32 VxD. The undocumented kernel32
> call, VxDCall, calls into this and other VxDs. Thus, GetLongName,
> calls sets up the necessary registers, and then calls VxDCall.

> I'm sure there's an easier way, but this was highly instructive and
> very interesting. I don't guarantee the results, but everyone is
> welcome to try GetLongName for themselves.
> --

        Well, I don't know whether it counts as "easier", but (as I
suggested some time ago) FindFirst works just fine for this. (I lied,
I think it is easier.) You can use the API FindFirstFile to go in either
direction.
        A person worried about wildcards could use FindFirst and
FindNext, I think.

--
David Ullrich
Sig file accidentally deleted - sorry.

Re:Long to Short filenames and vice versa


I've been following this thread with interest but what does all this
amount to in Delphi 16-bit?

Once you get the long name, how can you save, access, or create a file
using the dialogs (or even one you create yourself?)?

Delphi's 16-bit code simply won't allow non-standard 8.3 file access
anyway?

Unless, there is a way to over-ride this default behavior using 16-bit?

Re:Long to Short filenames and vice versa


Quote
Bard dZen <bard-d...@utech.net> wrote:
>I've been following this thread with interest but what does all this
>amount to in Delphi 16-bit?
>Once you get the long name, how can you save, access, or create a file
>using the dialogs (or even one you create yourself?)?
>Delphi's 16-bit code simply won't allow non-standard 8.3 file access
>anyway?
>Unless, there is a way to over-ride this default behavior using 16-bit?

In Delphi 16 bit, you simply can't use long filenames. It is 16 bit,
not 32. That is the key.

Cheers,
Damien

========================================================
Are you a shareware programmer? E-mail me for info on
something I'm writing to make your life a lot easier!!!
=== "http://204.101.50.93/students/damien/dmhome.htm" ===

Re:Long to Short filenames and vice versa


On Fri, 21 Jun 1996 10:47:52 GMT, dmsm...@newcomm.net (Damien Smith)
wrote:

Quote
>In Delphi 16 bit, you simply can't use long filenames. It is 16 bit,
>not 32. That is the key.

This is not at all true.  All the long filename functions are
available to 16 bit programs.  It takes work, because the VCL won't
automatically use the long filename versions of the file functions,
but they're available.

Duncan Murdoch

Re:Long to Short filenames and vice versa


On Fri, 21 Jun 1996 10:47:52 GMT, dmsm...@newcomm.net (Damien Smith)
wrote:

Quote
>Bard dZen <bard-d...@utech.net> wrote:

>>I've been following this thread with interest but what does all this
>>amount to in Delphi 16-bit?

>>Once you get the long name, how can you save, access, or create a file
>>using the dialogs (or even one you create yourself?)?

>>Delphi's 16-bit code simply won't allow non-standard 8.3 file access
>>anyway?

>>Unless, there is a way to over-ride this default behavior using 16-bit?

>In Delphi 16 bit, you simply can't use long filenames. It is 16 bit,
>not 32. That is the key.

I am afraid that this statement is not correct.

If running under Win95 or WinNT 16bit software CAN access long
filenames. All you need is to call some Win32 API functions - made
easy with Call32NT (or callnt32) available as freeware at the Delphi
Super Page. You might want to take a look at TPW32_10.zip in
simtel-mirror\win3\delphi, too.

I started writing some routines myself but had to realize at some
point that this was a complete waste of time: Delphi 2 would do it
anyway and all this effort for just getting a 16bit app to access LFN?

--
Stefan Hoffmeister                       Stefan.Hoffmeis...@Uni-Passau.de
University of Passau, Bavaria, Germany   http://www.rz.uni-passau.de/~w4hoff01/

Go to page: [1] [2]

Other Threads