12-08-2017 09:18 AM
If you have an array that is 1 2 3 empty 5 empty 7, going into an auto-indexing For Loop, and you detect if the path is empty and wire that to a case structure so it does not run the subVI if the path is empty.
You could also search through the 1-D array of paths and delete any paths it finds are empty. Forward that now cleaned up array to the For Loop and the Read File. Now you don't need the case structure around the Read File.
It sounds like you have a user interface problem where the user needs to learn to right click and use delete from array if they want to get rid of an element rather than just blanking out an element in that array turning it into an empty path.
12-08-2017 10:25 AM
@RavensFan wrote:
If you have an array that is 1 2 3 empty 5 empty 7, going into an auto-indexing For Loop, and you detect if the path is empty and wire that to a case structure so it does not run the subVI if the path is empty.
You could also search through the 1-D array of paths and delete any paths it finds are empty. Forward that now cleaned up array to the For Loop and the Read File. Now you don't need the case structure around the Read File.
It sounds like you have a user interface problem where the user needs to learn to right click and use delete from array if they want to get rid of an element rather than just blanking out an element in that array turning it into an empty path.
You could also load all the paths as strings into a listbox, allow multiple selections and then process the paths per the item indices selected.
12-08-2017 10:48 AM
RavensFan,
The idea of search the 1D Array and deleting the empty ones will do exactly what I want. So simple...
You also are correct, the program will become an .exe and the users are not going to know (and might not be allowed actually) to edit the 1D Array of paths. They are going to simply point to certain files that they need for the test run and leave the other elements empty if need be.
Again, I just learned how to program in LabView a couple of months ago and, this is literally my first program (besides the exercises from the video training). And thanks for not loosing your patience in helping and for not being condescending, as some people can be.
Man...I'm kicking myself in the rear for that one because I just used the search 1D Array and Delete From Array on two other instances in the program...good thinking!
12-08-2017 10:57 AM - edited 12-08-2017 10:57 AM
@FarmerJ wrote:
The idea of search the 1D Array and deleting the empty ones will do exactly what I want. So simple...
Man...I'm kicking myself in the rear for that one because I just used the search 1D Array and Delete From Array on two other instances in the program...good thinking!
Even simpler to use conditional indexing tunnels.
12-08-2017 11:16 AM
Interesting...I'm going to look into that after lunch.
12-08-2017 09:11 PM
I like using the conditional formatting. Thanks!
12-09-2017 09:21 PM
@FarmerJ wrote:
It should do nothing. In my case, I want to use an Array of Paths which, at times not all paths might be needed. If I choose an Array of Paths and have a path empty in that array, then why would the .vi want to prompt me? If I chose all of the paths before I run the program, why would I want to treat the empty path differently? I do believe that most users would intend to not need that empty path if the other paths are filled in before RUN. Wouldn't you agree?
It sounds like you're pretty well set on your main issue now. You had some solid programmers weigh in.
I did want to touch on this post mostly because it sounds like you're newer with programming and this is a great place to take a look at some theory.
Nothing is almost always something. You noticed this later when you realized the internals would have to do something to realize the path is empty in order to do nothing with the empty path. The interesting part of this question is what do you do with the output? In order for a VI to finish, it HAS to send all of its outputs. If it does nothing, internally, what would an appropriate output be? This is often an interesting consideration to make when you're developing your own apps.
Your second idea hits on the idea of flexibility. There's an array of paths and not all are needed for every potential use case. How can we keep that flexible? The VI prompts for input with this flexibility in mind. If it didn't, you'd HAVE to know the path at edit time. If you didn't, you'd have to write some extra functionality to prompt the user for a path to use files that may not exist when the program was being written. There's three real ways to handle the empty path: prompt the user for an actual path, pass out an error, or "do nothing." The first gives the user a chance to fix the problem. The second lets the program know something wasn't right. The third pretends everything is ok and moves on. Of the three, the latter is my least desirable. I'd want it to either alert me it requires a path or throw an error so it's easier to debug my application when that takes place. Generally speaking, it's better to handle it these two ways because it forces a developer away from dangerous practices. For similar reasons, this is why I rarely check "Use Default if Unwired" for output tunnels.
12-10-2017 08:06 PM
Natasftw
The second option out of the three that you mentioned; will it send the error without prompting the dialog and still allow the program to function? I see that an error gets generated and passes it through but, when I choose to cancel in the prompt everything just stops.
12-10-2017 08:16 PM
It is somewhat debatable as to whether cancelling the file dialog should generate an error. It does generate error code 43. So you need to do something to handle it. Basically cancel it and do something special to work around the lack of having a filename being returned.