1. long filenames with command_line
I have created a WIN32 program that uses the command_line function to get
filenames from windows 95/98 for Drag-n-Drop operation. It works fine
except that I only get the short (~1) filenames from command_line. If I
manually type the command from a "run" prompt or a DOS window it keeps the
long filename. But with the Drag-n-Drop, I lose it. Is there a way to
get the long filenames to work with the Drag-n-Drop method so that the
output files that are created by my program can use filenames based on the
_long_ filenames of the input files?
Thanks.
Dan Ferguson
2. Re: long filenames with command_line
- Posted by Joe Otto <joeotto at SWBELL.NET>
Jan 27, 2000
-
Last edited Jan 28, 2000
Dan,
I'm not aware of any way to get drag-and-drop to use long filenames. But
you *can* take the short filename that is passed and tell Windows to convert
it to the long filename equivalent with the GetLongPathName function.
Joe
-----Original Message-----
From: Euphoria Programming for MS-DOS
[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of Dan Ferguson
Sent: Thursday, January 27, 2000 8:59 AM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: long filenames with command_line
I have created a WIN32 program that uses the command_line function to get
filenames from windows 95/98 for Drag-n-Drop operation. It works fine
except that I only get the short (~1) filenames from command_line. If I
manually type the command from a "run" prompt or a DOS window it keeps the
long filename. But with the Drag-n-Drop, I lose it. Is there a way to
get the long filenames to work with the Drag-n-Drop method so that the
output files that are created by my program can use filenames based on the
_long_ filenames of the input files?
Thanks.
Dan Ferguson
3. Re: long filenames with command_line
Greetings!
I could not find a function named GetLongPathName. I do find
GetFullPathNameA in kernel32.dll. While the Win32 Programmer's
Reference says it will expand the filename to longfilename version,
it doesn't do that for me. Instead it seems to merely append the
current drive and directory to a given filename. Passing in a fully
qualified short name just spits the same back out. Anyone else
have different results?
I have a function which calls dir for each piece of a file's path and
appends the resulting long filenames together to get a full
longfilename path, but a quicker, cleaner method would be nice.
John Cannon
High Top Mountain Cottages
http://www.mountaindog.net/
4. Re: long filenames with command_line
----- Original Message -----
From: John Cannon <jzcndd at EARTHLINK.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, January 29, 2000 3:00 PM
Subject: Re: long filenames with command_line
> Greetings!
>
> I could not find a function named GetLongPathName. I do find
> GetFullPathNameA in kernel32.dll. While the Win32 Programmer's
> Reference says it will expand the filename to longfilename version,
> it doesn't do that for me. Instead it seems to merely append the
> current drive and directory to a given filename. Passing in a fully
> qualified short name just spits the same back out. Anyone else
> have different results?
>
> I have a function which calls dir for each piece of a file's path and
> appends the resulting long filenames together to get a full
> longfilename path, but a quicker, cleaner method would be nice.
>
> John Cannon
> High Top Mountain Cottages
> http://www.mountaindog.net/
>
Dos7 has the same interrupts as dos6.22- ,, with the addition of the extra
register for the longfilename data, plus others. I haven't done dos in a few
yrs, but i assume you can use the same int calls as you use now (but not
windoze api calls) and just look in a diff place for the longfilenames in
your code,, which is what i did long ago in pascal. It's an easy way to
translate, doing any getdata int call on the file should do the translation
to/from long/short as part of the returned data on any dos7 int call.
Example:
dos6.22- GetCurrDir = int21, function 47h
dos7+ GetCurrDirLFN = int21, function 7147h (DS:SI points to the LFN, all
other calling and returning registers are the same as dos6.22- )
new int 21h, 71A0h = GetVolInfo returns max path length allowed.
All the LFN functions are accessed by "71h" & the old function. Realmode
tsr's loaded at boot time can't use LFN, unless the right series of vxd are
pre-loaded.
Kat,
not really thinking atm,
but thinking lack of filename translating in the windoze API makes some
sense,, it *is* microsoft, after all.
