Does anyone know how to return the dos 8.3 short filename for a file or directory given its long name?

I've searched this site and the closest thing I could find was a utility by Steve Smith to do this in Arev.

Paul,

Does anyone know how to return the dos 8.3 short filename for a file or directory given its long name?

Well if you've got our Utility32 product you can use that , otherwise check out the GetShortPathName() Windows API call which should do the job for you!

The Sprezzatura Group

World leaders in all things RevSoft

We have similar long to short / short to long filename conversion routines compatible with FAT and NTFS (Good for AREV & OI16 & OI32). They are also written by Steve Smith, (as the original utilities used a call obsoleted by Microsoft after Win 9x). These involve shelling out to run an external 32-bit Windows executable.

We have Utility 32, which offers similar functionality for OI.

And then there's the standard Windows API calls, which you can prototype and call direct from OI32.

The Sprezzat.ura Group

World Leaders in all things RevSoft

Thanks, getshortpathname sounds like what I need.

Do you know what DLL this resides in for prototyping purposes and the required parameters. (win2000)

Regards

Paul

The function is in the library kernel32.dll.

The first parameter is the lpszLongpath being retrieved (string), the second is the lpszShortpath as a buffer for the result (string), and the third is cchbuffer (a long integer) - being the length of the populated lpszShortPath buffer.

The function returns as type long, the length of the lpszShortpath result.

The Sprezzatura Group

World Leaders in all things RevSoft

It must be obvious now that I don't know what I'm doing!

I added the line

ULONG STDCALL GetShortPathName(lpszLongpath,lpszShortpath,cchbuffer)

to the DLL_KERNEL32 record in SYSPROCS. I'm not sure what the first 2 keywords mean. I'm doing this by deduction rather than understanding what I'm doing. Anyway, after adding that line, I perform call declare_fcns("DLL_KERNEL32"). (Theres a windows beep. Not a good sign)

When I try to test the getshortpathname function, I get an error saying. "Function GetShortPathName does not exist in Dynamic Link Library KERNEL32."

A text search at dos on the kernel32.dll file shows that at least the text "getshortpathname" exists in there.

Any Ideas? Have I failed to show it who's boss?

Paul,

2 problems. When prototyping functions you have to declare the *type* of variable you are dealing with, not the actual name used so change your declaration to:

ULONG STDCALL GetShortPathNameA( LPCHAR, LPCHAR, ULONG ) as GetShortPathName

And then do:

'RUN DECLARE_FCNS "DLL_KERNEL32"' in the System Editor. This way if there's any problems with the function you'll see them in the results viewer.

Next thing is you'll see is that I've declared the function as GetShortPathNameA. This is because GetShortPathName, like many Win32 API functions, has an ANSI version (GetShortPathNameA) and a Unicode version (GetShortPathNameW). These are the functions exported from Kernel32 which is why OI can't find a simple GetShortPathName.

Currently OI32 is an ANSI application so we need to use GetShortPathNameA. However you'll also see I've aliased it as GetShortPathName so you don't have to put the 'A' on the end when you use it in your Basic+ code.

The Sprezzatura Group

World leaders in all things RevSoft

Thanks. Now that bit works, it doesn't get the missing from dll message any more. I didn't realise that the function was actually called getshortpathnameA and needed to be aliased.

Now when I try to use it, it doesn't return the value that I'm expecting.

using

longpath=C:\downloads" ;* I've tried a few different paths here.

Shortpath="

cchbuffer="

ans=GetShortPathName(longpath,shortpath,cchbuffer)

I was expecting it to return "C:\DOWNLO~1" in Shortpath but it returns null. ans and cchbuffer are zero.

I reckon we must be close now. Any ideas?

Cheers

Paul

If I append char(0) to longpathname then ans=12. The length of the long path. The shortpathname is still null though. This is the bit of info that I'm after.

Paul,

I believe the code should be something like this (this is without even compiling for syntax errors):

longpath=C:\downloads":\00\ // The null byte won't be needed in 4.1
Shortpath=space(260)         // This must be preallocated
cchbuffer=len(Shortpath)     // Let GetShortPathName know the size of the buffer
ans=GetShortPathName(longpath,shortpath,cchbuffer)
// The returned ans is the length of the short path name,
// so truncate our buffer to the actual length
Shortpath=Shortpath1,ans

or some such…

Pat

Excellent!

Thanks Pat, that works.

Cheers

Paul

View this thread on the forum...