Short Path Name via VB.NET

[DIOS]

I have a legacy app from a manufacturer that requires a driver file
with a path in short format. The path is guaranteed to exist so there
are no problems there as I understand the path (or file) must exist in
order to make the conversion. I looked around a bit and found several
articles showing how to do this with an API call. Is there no native
method in the .NET framework that will give me this?

thanks
AGP

 

[Tom Shelton]

I have a legacy app from a manufacturer that requires a driver file
with a path in short format. The path is guaranteed to exist so there
are no problems there as I understand the path (or file) must exist in
order to make the conversion. I looked around a bit and found several
articles showing how to do this with an API call. Is there no native
method in the .NET framework that will give me this?

Nope. The API is the way to do it.

http://tom-shelton.net/index.php/2008/10/01/convert-a-long-file-name-to-a-short-file-name/

 

[JR]

Nope.  The API is the way to do it.

http://tom-shelton.net/index.php/2008/10/01/convert-a-long-file-name-...

Or you can work with fso
Dim fso As Object, f As Object, oFile As Object

Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.GetFolder(sPad)

Take a look at the propertys of f

 

[Tom Shelton]

Or you can work with fso
Dim fso As Object, f As Object, oFile As Object

Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.GetFolder(sPad)

Take a look at the propertys of f

Ok. Didn't know about that one.

But, there are a couple of reasons I wouldn't use it. The first is that given
the choice of of P/Invoke vs COM Interop - I'll lean toward P/Invoke because
it is usually faster (though, probably not much of an issue in this case).
The second reason is the same as why I never used the FSO stuff way back when
I acutally used VB... The fso is part of the scripting runtime, and in a lot
of cases has been disabled by system admins due to security - and besides that
it was slow in comparison to using the equivalent win32 api's...

 

[DIOS]

Ok.  Didn't know about that one.

But, there are a couple of reasons I wouldn't use it.  The first is that given
the choice of of P/Invoke vs COM Interop - I'll lean toward P/Invoke because
it is usually faster (though, probably not much of an issue in this case)..
The second reason is the same as why I never used the FSO stuff way back when
I acutally used VB...  The fso is part of the scripting runtime, and ina lot
of cases has been disabled by system admins due to security - and besidesthat
it was slow in comparison to using the equivalent win32 api's...

Very well. Will use the API. Seems to me that it being older tech that
MS is trying to distance itself from it going forward. That's my
guess. However there are still many legacy programs that I use in my
industry that are released based on DOS and require short names and
the 8.3 naming convention.

AGP

 

[JR]

Ok.  Didn't know about that one.

But, there are a couple of reasons I wouldn't use it.  The first is that given
the choice of of P/Invoke vs COM Interop - I'll lean toward P/Invoke because
it is usually faster (though, probably not much of an issue in this case)..
The second reason is the same as why I never used the FSO stuff way back when
I acutally used VB...  The fso is part of the scripting runtime, and ina lot
of cases has been disabled by system admins due to security - and besidesthat
it was slow in comparison to using the equivalent win32 api's...

Thats write. But i give the awnser becourse its easier to program but
less reliable
And i didn't know what language starter uses.
Anyway for old programs its maybe beter to rewrite them completly in a
new language

Jan

 

[DIOS]

Thats write. But i give the awnser becourse its easier to program but
less reliable
And i didn't know what language starter uses.
Anyway for old programs its maybe beter to rewrite them completly in a
new language

Jan

I agree its better to re-write them with up to date language. However
sometimes that is out of the users control. The programs are developed
by a manufacturer (and industry in general) that is still stuck on
FORTRAN77. I see a small shift in programming languages for newer
products but older products will always be based on older tech. That
will not change anytime soon.

AGP