The following code should return an empty string but it doesn’t
juce::File a = juce::File::getSpecialLocation(juce::File::SpecialLocationType::commonApplicationDataDirectory);
juce::File b = juce::File::getSpecialLocation(juce::File::SpecialLocationType::commonApplicationDataDirectory);
juce::String rel = a.getRelativePathFrom(b);
Thanks !
No… not sure that it should return an empty string.
I’d actually expect it to return something like “…/foo.txt”. What does it return?
well it does returns …/LastChildOfThePath
but it do not make sense imho.
I’m only talking in the case where both path are exactly the same right ?
I think it’s doing the right thing then. An empty string is used as a kind of error, like it says in the docs, that’s returned if the paths are invalid.
I disagree regarding the good behavior but I see how you cannot break the current behavior of returning an empty string as an error.
That’s life.
I think the behaviour’s the right thing - typically you’d use this to create a string that’s stored somewhere and which would make no sense to be blank, e.g. the projucer uses it extensively to create relative paths inside projects where a blank string would be meaningless, but a partial path would be fine.
as a middle ground
./
would make more sense.
+1, depending if “a” is a file or a directory…
if I remember correctly
. is for a file
./ is for a directory
my main grip with the current behavior and as you said it is used in Projucer, is that if I store this path and rename the directory, then the path is wrong even though it would have worked as those are in he same directory.
Seems bogus to me.
In the soon to be std::filesystem::path
boost::filesystem::path a("C:\\Windows");
boost::filesystem::path b("C:\\Windows");
auto rel = boost::filesystem::relative(a, b);
rel equals .
No distinction between dir or file
OK, I guess ‘.’ is a reasonable return value if the files are the same.
This of course assumes that they’re both referring to a folder, not a file, but the method isn’t supposed to be given a file anyway, so if you do that you’re already on shaky ground!
hahh, I was debugging today exactly the problem that @otristan described and thought this is a JUCE bug, so it was interesting to find this topic…
“I store this path and rename the directory, then the path is wrong even though it would have worked as those are in the same directory.”
I stored relative paths in preferences, but when I renamed the parent folder, it stopped working…
File("D:\\xxx\\yyy\\zzz").getRelativePathFrom("D:\\xxx\\yyy\zzz\\___\\!!!")
returns this, that I stored: "..\\..\\..\\zzz" instead of "..\\.." or "..\\..\\"
while I thought "zzz" is not stored as that's still common in both...
the extra "..\\zzz" is ok, but only until I rename "zzz" as I didn't thought that's part of the relative path as that's common part.
