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

[JÞB]

Overall nice but probably not quite ready to ship with LabVIEW (although a good hidden gem candidate)  I would probably have chosen the new or existing browse option over the existing option.

I'd like to see support for %T and perhaps even roll this into an Express.vi for that exact reason and to make it compatable with the configure multi file settings in the write to measurment file express.vi ( In fact- doesn't that code exist somewhere in 

C:\Program Files\National Instruments\LabVIEW 2013\vi.lib\express\express output\ExFileWriteConfig.llb\?)

[altenbach]

I actually typically use a slightly different procedure:

I simply append a hexadecimal tag based on the timestamp. Unless I try to save faster than once per second, the resulting filenames are globally unique and automatically also sorted historically (if the display is sorted alphabetically). In addition I can tell at all times when it was generated for centuries to come. 😄

Here's a simple draft of the core code: It can easily modified for e.g. better time resolution or to deal with files that don't have an extension, etc.

[AristosQueue (NI)]

Suppose that the VI took a strict VI Refnum as input whose input was an array of strings (where each string is a filename in the directory that has the same base as the colliding file) and whose output is a single string (the uniquified name). If you pass in Not A Refnum (the default), then the VI does what it does now. Otherwise, you can be as creative or not in the uniquification process as you desire.

[AristosQueue (NI)]

See attached for one possible implementation of my previous idea. Instead of getting the array of files, I just left it to iterate its trials.  You can pass in the "Timestamp File Name Uniquification Procedure.vi" instead of the standard one if you want.

In the .zip, "Create Unique File.vi" is the original VI, but renamed because some people wanted me to find a new name.

"Create Unique File Using Custom Procedure.vi" is the new version with the VI Reference.

Still saved in 2011.

[Darin.K]

There is no one-size-fits-all routine here, or even one-size-fits many one for that matter.  There are too many potential uses and personal tastes.

In the current VI:  I do not care about BD comments since this is supposed to be a black-box routine.  What I am more concerned with is the derth of control descriptions.  And why isn't Actual Path connected to the ConPane?  The context help mentions it which is odd when hovering over the subVI.  As a debugging tool it could be useful if you have it open when the error occurs, but that sort of thing warrants a control description IMO or a comment on the FP.   Of course once you connect it then the temptation arises to use it instead of the open refnum.  A primitive can at least close unwired refnums.  Given the choice, I'd prefer the VI to simply return the path and not open or create it.

I always use the next available number, not the first available one.

For data usage I would also not hammer the OS like this looking for filenames (even if the directory info is cached).  As a quick exercise, if you use it for 1000 files how many times is the Does File Exist? subVI called in the while loop?  (Hint: 1+2+3+...n is roughly n^2/2 for large n.)  That is why I would use a VI to find the next available number and then increment accordingly.

So let's assume we keep this far away from our large data folders, then I think the current system (no leading zeros) is a good default (nice that it is adaptable).  Just like downloaded files get (1) or (2) or sometimes (5), it seems rare to hit (10) or (100).  That seems to be the spirit of the request (small number of duplicates) and mitigates the n^2 scaling of the current method.

You have already combined two functions into a single VI (find the desired filename and then create it) which is a  violation of my tenets for reuse code.  Adding more functionality via more complexity is moving in the wrong direction IMO.  If this is going to ship with LV it should do one thing, do it very well, and be as simple as possible.

[AristosQueue (NI)]

> And why isn't Actual Path connected to the ConPane?

It should have been. Oversight.

[AristosQueue (NI)]

---

@Darin.K wrote:

(Hint: 1+2+3+...n is roughly n^2/2 for large n.) 

---

No. It is n/2, regardless of how large n gets. And this isn't 1+2+3... this is a linear search for the next unused number... 1+1+1+1... If you have 1000 files, you have at most 1000 calls.

@Darin.K wrote:
You have already combined two functions into a single VI (find the desired filename and then create it) which is a  violation of my tenets for reuse code.  Adding more functionality via more complexity is moving in the wrong direction IMO.  If this is going to ship with LV it should do one thing, do it very well, and be as simple as possible.

---

And there, folks, is the second hardest problem of API design. The first hardest is "what do we name this thing?" But right after that is, "How granular should the API be?"

Sure, I can break it into two separate VIs, but even if I do that, what's going in the palettes is almost certainly one operation. Why? Because if I put two in the palettes, I'll hear about it from a wealth of people that "I always use these together, why are you making me drop both of them or create my own subVI that I now have to maintain ... everyone is constantly creating their own subVI of these two together... can't you just give me ONE VI?!"

I'll contend that this does do ONE thing and do it well -- it creates a file without collision with an existing file. The question is how far to break the task down into useful chunks and how complex to make the packaging.

[AristosQueue (NI)]

---

@Darin.K wrote:
What I am more concerned with is the derth of control descriptions. 

---

You won't find control descriptions on the vast majority of vi.lib VIs. That contravenes our general style guide. Why bury useful information in such an obscure place? If it needs to be high priority for the user of the API, it needs to be in the CH for the VI. Lower priority goes in the online help for the VI. In this case, I don't have online help yet, so it goes in the CH for the VI. For me and mine, the control description is useful for VIs that are end-user user interfaces... which pretty much leaves out all library APIs.

Diagram comments are for people who are actually editing the VI.

[Darin.K]

---

@AristosQueue (NI) wrote:

---

@Darin.K wrote:

(Hint: 1+2+3+...n is roughly n^2/2 for large n.) 

---

No. It is n/2, regardless of how large n gets. And this isn't 1+2+3... this is a linear search for the next unused number... 1+1+1+1... If you have 1000 files, you have at most 1000 calls.

---

Head smack.  Consider how you got to the 1000 files.  By calling it once with 1 file, then once with 2 files, then once with 3 files, then once with 4 files, then once with 5 files.  That is n^2.  Test it if you do not believe me.

[JÞB]

No. It is n/2, regardless of how large n gets. And this isn't 1+2+3... this is a linear search for the next unused number... 1+1+1+1... If you have 1000 files, you have at most 1000 calls

If you create 1000 files the loop ran how many times?  1000 times for the last file + 999 for the file before that + 998 for the n-2th file....... and then I might have inadvertantly moved file # 499 but I still only want 1 of them I don't want the files generated 770, 499 ,771, 772.....  A folder list, sort and reverse should clean that up.