The Open/Create/Replace File Function with the Create operation does not create the file if the specified path leading to that file does not already exist. One has to use the separate Check if File or Folder Exists vi followed by the separate Create Function to first create the folder if it is found to not already exist and then actually Create the file with Open/Create/Replace File. It would be useful to not have to perform the already exists operation and simply provide the capability (perhaps as an input boolean option) to create the entire file's folder path if it does not already exist when using the Open/Create/Replace File Function to create a file.
Yes, the directory creation is only for "Create" or "Create or Open" options. Because the existing behavior is to not create the directory, that behavior probably needs to be retained. Thus to implement this feature would involve adding a boolean input to "Create path if non-existent". Steve
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
Shb: You don't need the Clear Error.vi in your picture. Wiring to border of the structure node is enough to ignore the error even if automatic error handling is enabled. And it gives you a convenient place (inside the structure) to put a comment about why you're ignoring the error.
Recent events made me want to post this idea. Good thing I did a search first. Anyways, consider this a bump.
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
Looking at shb's code above. You only want to clear error code 10. You get a "Duplicate Path" error if the directory already exists. Otherwise, it matches exactly with what I have in my reuse library.
I still think this functionality belongs in the primitives though.
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
Pretty sure this functionality was explicitly rejected from the primitive. You're free to write a higher level VI to implement this behavior using the primitives. Requesting that we add a higher-level VI to the palettes that does this is also a legitimate request. But the low-level API (correctly, IMHO) focuses on a single file.
(Relevant to other discussions on the forums this week, this is an example of publishing the API at one level and folks requesting the higher level combo function. The decision of when to publish the higher level as the published API, when to publish lower-level building blocks, and when to publish both [which risks user confusion, as we see commonly in our hardware APIs] is an art, not a science.)
I understand trying to find the balance. But ever since this file IO primitive was introduced (sometime around 8.2?), when I told it to create a file at C:\foo\bar.txt, I was always in shock when I get an error saying that it couldn't create my file because the directory foo did not exist. "File not found?!! You are supposed to MAKE the $#%@!#$ file!" At the very least, put a note in the help that this primitive does not create the directory structure. That would at least take care of some of the expectation.
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