Displaying Long Paths

[dthomson]

I was wondering if anyone had seen a LabVIEW routine for displaying long paths in a relatively short string. I did a search on the DevZone and found a CVI example, but nothing in LV.

What I would like is to restructure a path string so that it fits within a fixed-size string indicator, with the beginning of the path and the end (file name) visible. Due to proportional fonts, it should probably iteratively try truncating the path by different amounts until it fits the available space optimally.

Regards,

Dave T

[Mike Ashe]

A project I worked on about a year and a half ago did this, but without the iteration. If a path was going to be beyond "x" characters i used the path to array, indexed the drive, first directory and the VI name. It then inserted an ellipsis string ("...") in the array just before the VI name and rebuilt the path from the string.

Can't seem to find it, so I just did a quick version.*

No iteration, that is an exercise left to the student

And here is the VI: Download File:post-45-1159825177.vi

* For the regular's, yes the coffee is good at the moment ...

(Hey, we need a coffee cup emoticon!)

[jaegen]

...

* For the regular's, yes the coffee is good at the moment ...

(Hey, we need a coffee cup emoticon!)

Here you go:

[Mike Ashe]

Bless you Sir!

Hey Michael!, can we get this one added to the library of clickable smilies please?

[dthomson]

Thanks for the example, Mike. I got going on it a bit and ended up writing one that optimizes the string. Rather than counting characters, it takes the string indicator width, font, size, bold, and italics into account and comes up with the best fit. (Or at least it is supposed to.) I'll attach it here, and I'll be putting it on my website before long. I'd be glad to hear of any bugs or issues. I'm sure there are some edge cases that it doesn't handle well.

Regards,

Dave

Download File:post-1255-1159913289.zip

[Jeffrey Habets]

Very nice!

Personally I would prefer if the filename was prepended with a backshlash so it's clear to the user that he is seeing the complete filename.

e.g. C:\Program Files\Natio...\labview.exe

[dthomson]

Very nice!

Personally I would prefer if the filename was prepended with a backshlash so it's clear to the user that he is seeing the complete filename.

e.g. C:\Program Files\Natio...\labview.exe

Thanks! I agree about the "\" before the file name. I added that, but I won't post another version here quite yet so as not to clutter the site with too many revisions.

Another note: Although the internal code should all be platform independent, the logic assumes a Windows path syntax...

Regards,

Dave

[Mike Ashe]

Thanks! I agree about the "\" before the file name. I added that, but I won't post another version here quite yet so as not to clutter the site with too many revisions.

Another note: Although the internal code should all be platform independent, the logic assumes a Windows path syntax...

Regards,

Dave

I did the quick scratch version as an act of mercy literally between gulps of coffee on a very short break. I should have read your post closer, or, more accurately, your sign off block. I was in such a hurry I didn't register the name.

I agree with the slash before the filename. I might also suggest for your final version you give thought to LV 8.2 and also an older version like 6 or 7. Lots of people still using those.

Another thought would be to make it a bit more generic is to take a generic reference and figure out what type of control it is: string? listbox? path? and size from there. This would be really useful in a lot of multi column listboxes.

Bye the way, nice clean code :thumbup:

[syrus]

Thanks! I agree about the "\" before the file name. I added that, but I won't post another version here quite yet so as not to clutter the site with too many revisions.

Another note: Although the internal code should all be platform independent, the logic assumes a Windows path syntax...

Regards,

Dave

Hi David,

This VI will be very useful to me. I added the backslash and also added simple error in and error out terminals. Edited version is attached. --Syrus

Download File:post-3106-1160086183.vi Edit: Requires LV 8.2

[Ton Plomp]

Hi David,

This VI will be very useful to me. I added the backslash and also added simple error in and error out terminals. Edited version is attached. --Syrus

Download File:post-3106-1160086183.vi Edit: Requires LV 8.2

Hi Syrus,

I took the liberty in converting your VI into an Xcontrol, but cannont upload right now. Hopefully tonight (CET) If anyone is interested they can PM me.

Ton

Edit:

Not tonight, but saturday

Thoughts for future:

remove the browse button if it is an indicator

Have right click control over browse options.

[dthomson]

Thanks for the additional ideas. I agree that the error in and out should have been included. As for other data types: My newest example shows how to wire it up for an array of strings (as well as just a string), mostly because that is a particular case that I am planning on using. A listbox would be nice, but I haven't gotten to that. As for a path indicator - my first reaction is that that would be a rather strange use case, since the path being written into the indicator is no longer a valid path. However, as soon as anyone says "no one will ever possibly want to do that", someone will point out a valid use case...

But the path indicator combined with the XControl idea brings up an interesting possibility. I'm not too familiar with XControls, so I'm not sure what all is possible. But how about an XControl version that displays the truncated path, but returns the entire original path to the data wire? Or could it even have two outputs (or two types of output that are somehow selectable), the truncated version and the entire original path?

Regards,

Dave

[Ton Plomp]

But the path indicator combined with the XControl idea brings up an interesting possibility. I'm not too familiar with XControls, so I'm not sure what all is possible. But how about an XControl version that displays the truncated path, but returns the entire original path to the data wire? Or could it even have two outputs (or two types of output that are somehow selectable), the truncated version and the entire original path?

Guess you didn't open the XControl?

Don't worry I almost finished the item, only I think in placing it in the Code Repository

Ton

[dthomson]

Guess you didn't open the XControl?

Don't worry I almost finished the item, only I think in placing it in the Code Repository

Ton

Ton,

Yeah, I should have tried your XControl first. I did download it now and tried it. Nice job!

One other limitation I should note: My VI only works well for single-line string indicators. It shouldn't be too hard to modify it for multi-line indicators. Anyone care to give it a whirl?

Regards,

Dave

[Ton Plomp]

Ton,

Yeah, I should have tried your XControl first. I did download it now and tried it. Nice job!

One other limitation I should note: My VI only works well for single-line string indicators. It shouldn't be too hard to modify it for multi-line indicators. Anyone care to give it a whirl?

Regards,

Dave

Hi Dave,

I have modified your code, and expanded the xcontrol i posted earlier. This Xcontrol is submitted to the code repository and waiting on approval.

I have been thinking about multi-lineness, but am not sure how to implement it.

I can think of the following items:

original path:

c:\dataandstuf\somemorestuff\somedeepstuf\Reeldeepstuff\foo.stuf

Mullti-line 1

c:\dataandstu

f\so...\foo.stuf

Multi-line 2

c:\dataan...\

so...\foo.stuf

Summarized:

1. Only truncate at the end
   
2. Truncate every line
   

What do you think?

Ton

[Mike Ashe]

I have been thinking about multi-lineness, but am not sure how to implement it.

I can think of the following items:

original path:

c:\dataandstuf\somemorestuff\somedeepstuf\Reeldeepstuff\foo.stuf

Mullti-line 1

c:\dataandstu

f\so...\foo.stuf

Multi-line 2

c:\dataan...\

so...\foo.stuf

...

What do you think?

I think by "multi line" we would mean listboxes or tree controls fed by an array of paths, not a multi line string control. The tree control is an especially difficult problem since you might have to retruncate for different branches which might have more or less room.

List Boxes or Multi-Column Listboxes are next. Given an array of paths and a reference to the control, and a column number (if MCLB) read the available column width, then convert and truncate the strings and populate the rows of the control. For a real bonus you could detect a mouse up event on the listbox, then check if the user resized a column and if so, rerun the truncation VI.

[dthomson]

I think by "multi line" we would mean listboxes or tree controls fed by an array of paths, not a multi line string control. The tree control is an especially difficult problem since you might have to retruncate for different branches which might have more or less room.

List Boxes or Multi-Column Listboxes are next. Given an array of paths and a reference to the control, and a column number (if MCLB) read the available column width, then convert and truncate the strings and populate the rows of the control. For a real bonus you could detect a mouse up event on the listbox, then check if the user resized a column and if so, rerun the truncation VI.

I think all of Mike's ideas are worth pursuing, but actaully, I was thinking of multi-line string indicators. Your questions are good ones, Ton. I guess my initial assumption was along these lines:

Find the number of lines in the indicator. (If necessary, find the height and divide by the height of the font.)

Find the max number of characters that fit in that many lines, using the rules already defined in the original VI.

Let the result wrap however it wants.

So, basically, your option 1. Partly because it is simpler. The logic for Option 2 gets messier. But in some sense, your Option 2 is also harder to read.

Regards,

Dave

[Ton Plomp]

The file is accepted into the Code Repository:

Code Repository

Any thought improvements over there!

Ton