01-09-2011 04:31 AM
Food for thought.
Wow, i like that. Stripping a path using Build Path? Who would of thought. Seems like this would of been a better feature for 'Strip Path'? Will have to remember that one.
01-09-2011 12:12 PM - edited 01-09-2011 12:14 PM
@jvh75021 wrote:
I use the function Current VI's path and then pass the value to strip path. I know I need to go up three levels but putting multiple strip paths end to end yields the same path each time.
Maybe it is just a language thing, but I don't understand your statement "yields the same path each time".
"Same" as what? Are you saying that placing multiple "strip path" in sequence does not work right?
The suggestions to convert the path to string and back is not good, because it is OS specific and makes the VI non portable. The required string operations depend on the OS.
Also, Darin's method is windows specific and might not work on e.g. Mac or linux (I have not tried). You really should stick with the native path functions.
So, in order to strip a path N times, you would simply use a FOR loop as follows:
(If you feel you need that very often, wrap it into a subVI.)
01-09-2011 09:59 PM
In case you lose sleep over platform independence:
I avoid portability issues with paths two ways (the few times I care): (1) I have a subVI which simply returns the platform dependent separator (2) I have a second subVI which fixes paths so the separator is correct. This actually has never been used by me for portability, it is used to catch the MUCH more common problem of user input with the wrong separator. Easy to do when you bounce between Windoze and Linux.
I see a lot of near Rubes with people reconstructing relative paths instead of letting the build path primitive do its job.
01-09-2011 10:29 PM
Thanks. Your way is mo betta than mine, maybe. But matching the directory name seems easier than calculating where to stop the array subset.But I am no array expert. Final path is longer on my development system due to SCM
This will strip the path based on the Directory name you insert. Is also case insensitive.
Rgs,
Lucither.
01-10-2011 02:19 PM
@Darin.K wrote:
Food for thought.
Darin,
This is most excellent. You initialize an array with "go up one level" syntax. Later you build a path. But what is that little hootus between the array init and the build path? I have looked at string, file and array functions and cannot find it.
thanx,
jvh
01-10-2011 02:26 PM - edited 01-10-2011 02:27 PM
@altenbach wrote:
@jvh75021 wrote:
I use the function Current VI's path and then pass the value to strip path. I know I need to go up three levels but putting multiple strip paths end to end yields the same path each time.
Maybe it is just a language thing, but I don't understand your statement "yields the same path each time".
"Same" as what? Are you saying that placing multiple "strip path" in sequence does not work right?
The suggestions to convert the path to string and back is not good, because it is OS specific and makes the VI non portable. The required string operations depend on the OS.
Also, Darin's method is windows specific and might not work on e.g. Mac or linux (I have not tried). You really should stick with the native path functions.
So, in order to strip a path N times, you would simply use a FOR loop as follows:
(If you feel you need that very often, wrap it into a subVI.)
Thanks but it did not work for me. I fed something like C:\a\b\c\file.vi into the stripper function and fed the output into a 2nd copy of the stripper fn. I put indicators on both outputs and both yielded C:\a\b\c.
01-10-2011 02:34 PM
Concatenate Strings
01-10-2011 02:47 PM - edited 01-10-2011 02:47 PM
@jvh75021 wrote:
Thanks but it did not work for me. I fed something like C:\a\b\c\file.vi into the stripper function and fed the output into a 2nd copy of the stripper fn. I put indicators on both outputs and both yielded C:\a\b\c.
Can you attach a small VI that shows the problem?
Works fine here....
01-10-2011 03:35 PM
@jvh75021 wrote:
@altenbach wrote:
@jvh75021 wrote:
I use the function Current VI's path and then pass the value to strip path. I know I need to go up three levels but putting multiple strip paths end to end yields the same path each time.
Maybe it is just a language thing, but I don't understand your statement "yields the same path each time".
"Same" as what? Are you saying that placing multiple "strip path" in sequence does not work right?
The suggestions to convert the path to string and back is not good, because it is OS specific and makes the VI non portable. The required string operations depend on the OS.
Also, Darin's method is windows specific and might not work on e.g. Mac or linux (I have not tried). You really should stick with the native path functions.
So, in order to strip a path N times, you would simply use a FOR loop as follows:
(If you feel you need that very often, wrap it into a subVI.)
Thanks but it did not work for me. I fed something like C:\a\b\c\file.vi into the stripper function and fed the output into a 2nd copy of the stripper fn. I put indicators on both outputs and both yielded C:\a\b\c.
When trying to recreate the code shown above, did you remember to change the tunnels to shift registers?
01-10-2011 03:42 PM - edited 01-10-2011 03:43 PM
Cory K wrote:When trying to recreate the code shown above, did you remember to change the tunnels to shift registers?
Even tough he quoted an entire post, I don't think he's talking about my code suggestion, but is refering to my quote:
"... Are you saying that placing multiple "strip path" in sequence does not work right?".
When putting two strip path end-to-end, no shift registers are involved. I suspect a crossed wire. 😉