LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

A helpful VI to create a new file without colliding with existing

In response to this idea on the LabVIEW Idea Exchange:

Append auto incrementing number to the file name if file already exists

I am posting this VI for anyone who needs this functionality. I've added it to the list of potential VIs to consider shipping with a future LabVIEW.

Please post any comments about modifications to this VI to the Idea Exchange thread.

 

The VI is saved in LV 2011.

Message 1 of 48
(5,532 Views)

If this was an internal code review, I'd be yelling at you left and right about a lack of comments.

 

And Icon view on the terminals?Smiley Mad

 

The only real comment I have is that when I try to open the VI, it is looking for a VI you apparently have overwritten since it was looking for Error Cluster From Error Code.vi inside of <LabVIEW>\Mercer\error.llb.  LabVIEW found the "real" version without an issue though.  If this was for a future version of LabVIEW, I think I would push for the error ring instead anyways.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 48
(5,494 Views)

Hi Aristos,

 

thanks for sharing.

 

Could you please check your VI: when trying to open it with LV2013 it is searching for a subVI "...\LabVIEW 2013\Mercer\error.llb\Error Cluster From Error Code.vi", which is found at "...\LabVIEW 2013\vi.lib\Utility\error.llb\Error Cluster From Error Code.vi". Quite funny that search path…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 48
(5,490 Views)

Relink should be fixed.

 

Crossrulz:

Icon view is standard for LabVIEW and I consider it to be best practice for a long list of reasons.

As for comments, what comments would you add? The VI is documented and the code is legible. I documented the only tidbit that I considered interesting which is why I didn't include the prompt ability and documented the error codes. I didn't use the Error Ring in order to facilitate Save For Previous (2011 doesn't have the ring). Any comments I would make on functionality through code this simple would just repeat the context help of the nodes.

0 Kudos
Message 4 of 48
(5,475 Views)

I wouldn't document anything else except the regular expresion (as I have a hard time reading regular expressions).

0 Kudos
Message 5 of 48
(5,451 Views)

@drjdpowell wrote:

I wouldn't document anything else except the regular expresion (as I have a hard time reading regular expressions).


It is identical to the one used in get File Extension.vi. 🙂

 

(... there it actually is documented as : "Get all characters after the last period in the filename"). 😉

0 Kudos
Message 6 of 48
(5,432 Views)

What i find very important to know in the context of "counting files" is how to get a fixed length of numbers. In order to achieve this, you have only to modify the format string in Stephen's VI.

Let's say, your number shall always have a width of 3 digits with pre-pended '0', the format string would look like this:

"_%03d".

 

The result for "test.txt" would be:

test_001.txt

test_002.txt

.

.

.

 

EDIT: In this case, the only thing to take care of is that numbering will only start if the filename is already present......

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 7 of 48
(5,372 Views)

Norbert_B wrote:

Let's say, your number shall always have a width of 3 digits with pre-pended '0', the format string would look like this:

"_%03d".

 

The result for "test.txt" would be:

test_001.txt

test_002.txt

 


funny enought, that exactly the format I tried first when testing the VI yesterday. 😄

 

The main reason (that you have not mentioned) is the fact that file are now also sorted numerically even if the sorting tool only sorts aphabetically. I we don't do that File(10).txt goes before File(9).txt, for example while File(09).txt always goes before File(10).txt as expected.

 

The Windows 7+ file explorer does some magic mixed sorting so things look typically much better than expected, but this no longer applies e.g. if you sort your own list of files, e.g. from the output of a "list folder" function. LabVIEW sorts arrays of strings alphabetically (as it should, of course!).

 

Defining a fixed-width, zero padded format is always strongly recommended and the only comment I have for Stephen that maybe a fixed width format should be the default.

0 Kudos
Message 8 of 48
(5,336 Views)

altenbach wrote:

Defining a fixed-width, zero padded format is always strongly recommended and the only comment I have for Stephen that maybe a fixed width format should be the default.


How many zeros would you include? That's the question that bugged me when I contemplated that format. It's part of why I made the format an input to the VI -- that and the space before the parentheses (I avoid spaces in file names in pretty much anything that is a data file, which is a prime use case for "pick the next index" file naming).

 

As someone else mentioned, file systems have gotten smarter about listing these when the zeros are missing. I'm open to adding some default zeros.

 

A thought: I could make it " (%01d)", so that when you create a constant you can easily just increment the number rather than remembering how to do it.

 

Another question: If the file name passed in already has the count on the end of it, should I add a second index or process the first index? I decided in this VI to add a second index because the user's format string might be arbitrary and I wasn't confident in my ability to parse it off the end of the file name. So if you pass in "c:\abc (2).txt" and that already exists, you'll get "c:\abc (2) (1).txt".  If the index was on the front of the file name, I could just use the input format string to parse the number off the front and use that as a starting point, but being embedded at the end is a lot trickier.

0 Kudos
Message 9 of 48
(5,323 Views)

AristosQueue wrote:

A thought: I could make it " (%01d)", so that when you create a constant you can easily just increment the number rather than remembering how to do it.


 Exactly.

 


@AristosQueue (NI) wrote:

Another question: If the file name passed in already has the count on the end of it, should I add a second index or process the first index? I decided in this VI to add a second index because the user's format string might be arbitrary and I wasn't confident in my ability to parse it off the end of the file name. So if you pass in "c:\abc (2).txt" and that already exists, you'll get "c:\abc (2) (1).txt".  If the index was on the front of the file name, I could just use the input format string to parse the number off the front and use that as a starting point, but being embedded at the end is a lot trickier.


The code would need to be smart enought to decide if the current filename numbering exactly matches the format that was speficied in the current call. Many of my files already end in numbers and I agree it seems safer to append than trying to edit.

Another question is to decide on the actual number to use next. For example if the user had file.txt and generated file(00).txt ... file(55).txt and then deletes file(40).txt. Should the next generated file be file(40).txt or file(56).txt? I would probably prefer if the numerical order matches the historic order.

 

Yet another question is if the first file should be "1" or "0". I would probably prefer "1", so I can potentially rename the original file to "0" so it fits into the series more nicely.

0 Kudos
Message 10 of 48
(5,312 Views)