The use case for this idea is already fulfilled by the use of path notation (e.g. ..\..\) with the Build Path function. Duplicating this functionality on Strip Path would provide minimal additional benefit.
It would be nice if the Strip Path function had a recursive option rather than having to string Strip Paths together or use an external loop.
Kudos, but this would need to be used with caution, if the path level were ever to change. You could program-in a robust Expected Path? checker, which might traverse through stripped paths until the Expected Path is found.
This is one of those ideas that makes you wonder how nobody thought of it years ago.. I think it will help make File I/O code much cleaner and I'm pretty sure I'd use it almost every day.
you could also include a return boolean or two to handle the empty path or Not a Path. As to whether Error Cluster(s) are included and the function returns errors, it's a good point. How many times do we wrap functions up so that there is an error in / error out.
While I see the functionality as being useful is some cases, changing core functions is always problematic. Especially if you're talking about adding an integer input and error I/O. What would happen if you try to downconvert code that uses this new version? Perhaps creating a separate function, such as "Strip Path (Recursive)" would be better. If you try to downconvert code that uses this function it could be replaced with a subVI. Whether or not the downconversion mechanism could do that is a different question though.
Replacing it with a subVI when downconvertinng sounds reasonable.
This downconverted subVI could be broken (by intention) and the block diagram could contain a comment like "cannot downconvert Strip Path Recursive".
