We're working on a little shell utility that displays paths in a menu. Some of these paths can get rather long, so I cooked up this little regular expression to shorten them. It's a replacement, so you call it like this:
Dude?! Is that C# code on your blog? 
Yep. I am bilingual now.
VB is still better, though. I also prefer Pepsi.
Could I suggest tweaking the replacement string so that it uses three rather than two dots? As it stands, the resulting abbreviated path looks just a little too much like a proper path.
Go w/ the regex, a little more platform independent… if any at all.
I would go with PathCompactPathEx.
Reasons:
If you are using WinForms (it isn’t clear), you can use the StringTrimming property of a StringFormat object to control how text is written using Graphics.DrawString().
StringTrimming.EllipsisPath is probably making use of PathCompactPathEx under the hood.
I’m not suggesting it is a better solution than the other 2, just mentioning it as available option in the specific Graphics drawing scenario.
Ah, this takes me back - this task was my very first attempt at programming way back when I was doing my thesis on VAX/VMS and was a biologist not an IT developer.
I used it to get the prompt to display the current directory.
I probably would not have consciously remembered this outside of reading this article.
Hi,
I agree with Mihai: Consistency is key here. Whenever you want to do something and the Windows API provides a solution for it, you should go with that. Because, once everyone does that, every application works the same which is good for general usability (lower learning curve).
Now I agree that shortening paths is something with a lower impact on usabliity than, say, file open dialogs, but aonsistency still is a nice thing to get.
And imagine Microsoft doing something fancy to that routine in the future (maybe a genious will find a whole new (and better) way for shortening paths or maybe windows will begin interpreting control sequences in character strings put to labels for example to display additonal UI (maybe a tooltip or something) so the whole path can be displayed after all (just speculating here. I’m not saying it’s an intelligent thing to do).
If you use this routine, you will automatically be able to take advantage of such changes.
Philip
Your captcha is broken: It’s always the same word I have to enter (orange) - even with different browsers, so it’s no cookie thing.
Really? Are you sure you’re not a robot? Have you checked recently?
Jeff,
yes, I’m sure. It’s always the same word. Even after cleaning the cookies, the word stays the same. But seeing the pictures URL, I guess it’s indended.
I guess the spammers tools are too simplistic to even attempt to break the captcha. Probably because each site would require a different sort of processing which is just too expensive to do with all the non-captcha’d blogs out there.
Nice idea.
I guess even “Please type gnegg blow” would do it.
At least for now.
Philip
Jeff,
I think I understand more quickly that an abbreviated path is being displayed when I see a directory name that seems cut short by the ellipses. Looks like the Windows API method would do that in a larger percentage of the cases…
/k
Pepsi?
Philistine!
Came across this old page while Googling for Long File Paths and
I found it interesting.
Here’s a cobbled reference file of mine that might be of help to someone out there. Specifically, see pages 6-11.
www.fccss.net/evectory/osesame_longfilepaths.pdf
Send comments to Support@fccss.net
Thanks for the read! ciao!
DKWagner
That’s actually a very useful function, I remember kludging many a solution to this in pre-.NET apps (i.e. no native regex support).
I do have to call you on one thing though: your routine name is a noun, not a verb!
Beware: the code has opportunity for a buffer overflow, because StringBuilder sb = new StringBuilder(); creates a buffer with 16 characters only. Use StringBuilder(length) or perhaps StringBuilder(260) (260 is MAX_PATH) instead.