Printable View
Is there an easy way to get the relative path of a file? I mean if I specify a file/path and then another path is there some function/DLL/User Made Class out there that will return the path including all the ../../../../Folder1/Folder2 stuff? There has to be an easy way to do this.
Take a look at this thread .
That was a start, but what I really need to do is make a path relative based on another path AND unfold that path.
speak english do u mean something likeQuote:
Originally Posted by eyeRmonkey
dim path as string
path = replace(commondialog1.filename,commondialog1.filetitle,"")
No, that is not what I mean high6. I mean something like this.
There should be a corrosponding function to undo it. I think the one JA posted in the thread that RhinoBull posted will work.VB Code:
Let me explain what I am doing, because maybe I don't even need to do this.
I am making a file similar to a Visual Basic project file (*.vbp) and I want to make the paths relative so that if the project file is moved or changes computers or whatever, then the files will still open properly. Does that make sense?
eyeRmonkey,
Relative paths between computers are NOT relative. Relative can only be relative to an absolute. So if the absolute changes... it's not relative anymore.
Example:
a relative path like ..\..\..\somefolder
if moved to c:\folder has no real meaning relatively.
Lets assume there is a file structure like this:
So if the project file (*.vpb for exmaple) is stored in the folder labeled project and holds the path for a file in Forms wouldn't it be like this: "..\Forms\frmMain.frm"Code:C:
| - Projects
| - My Project 1
| - Modules
| - Forms
| - Project
| - Misc
Now if the whole "My Project 1" folder was moved, that relative path would still be valid. I need that same effect for my project files. That is why I need a MakeRelative() function and a MakeAbsolute() or Unfold() function so that I can still open/save the file using absolute paths, but I can store the paths relatively. The path they would use as an absolute would be the path of the project file.
eyeRmonkey,
Thats fairly simple. Let's say your project is is in Project1 and your forms are in the forms folder. Get the full pathname of the forms then remove the full path of the project and add ..\ to the front of the remaining path.
Yes, but that is only if I know it is one folder back and such. If it is very complex or many folders forward (instead of backwards and then forwards) then it becomes more complicated. I was really hoping there was a class around that someone had already written would help me out here.
eyeRmonkey,
It's not normally done due to it's inacuracy. You cant go forward relatively only backaards. But ask I have said Relative is only relative to an absolute. A Relative value cannot be relative to another relative value. They both have to be relative to absolutes. So you definitely need an absolute to start with then you can use relatives.
As I said above the relative would relative to the ABSOLUTE path of the current path of the project file itself.
Why can't you go forward relatively? Maybe its not called relative but if I used the project file as an absolute couldn't I just go forward to:
modules\module1.bas
That way if the whole folder is moved then it would still work. Just like if you had to go back a folder and then forward.
Okay, if I am not on the right track, then how does visual basic do it with their project files? Or how SHOULD I do it?
eyeMonkey,
You can't go forward relatively for the following reason. You have three folders in your Project1 folder now you want to move forward one folder...OK, now which folder is supposed to be relative??? By Sorting order? Which one? Name, Date, Modified Date... and so on. You have to have ABSOLUTE names to go forward.
VB ATTEMPTS to do it. Guaranteed, move the Project from the Project 1 Folder to c:\Folder and watch it have problems telling you it cannot load things.
Maybe I am missing something, but here is how i see it working (2 examples, both using the folder tree I listed above):
EX 1 - The project file is in the My Project 1 foler. In the project file woulb be:
Now, since the project i in C:\Project\My Project 1\ the program would interpret those paths like this:Code:Modules\modMain1.bas
Modules\modAPI.bas
Forms\frmMain.frm
C:\Project\My Project 1\Modules\modMain1.bas
C:\Project\My Project 1\Modules\modAPI.bas
C:\Project\My Project 1\Forms\frmMain.frm
EX 2 - Now the project file is in C:\Project\My Project 1\Projects and the contents of the file are this:
The output would be exactly the same as above because it goes back 1 folder (into My Project 1) then goes forward the right number of folders. I know this isn't a perfect situation because if the project file is moved then it won't work and if the any of the filesm move it also won't work, but I don't see a much better way of doing it.Code:..\Modules\modMain1.bas
..\Modules\modAPI.bas
..\Forms\frmMain.frm
Also, how do you reccomend I make a project file? I want it to be able to be moved from one computer to another and still work. The only solution I see is relative paths.
eyeRmonkey,
It will work, but not in all situations. The situation has to be perfect for it to work. So you are counting on luck in the placement of the project for it to work. If you used your first example, that wouold work in all cases. however the second one would only work if the project was place two or more folders deep. If it were place one folder deep it would fail.
I understand that it is not foolproof, but once again, what would you suggest instead?
eyeRmonkey,
The best way is the first example you posted. The project would alway know where it is and would just have to append where the form, modules etc are. As long as they stay in that structure.
But what happens if the user wants to add a file that is in a different part of the file structure (that would require relative paths). Should I force the user to make the file be above the project file in the current directory setup (IE - No backward/relative paths)?
eyeRmonkey,
That's the only way it would definitely work on another computer unless you copied the whole file structure over to the other computer including the folder structure where the new files are.
I understand the limitations. It is somewhat bothersome to get "File Not Found" when I open other peoples VB project files, but IMO it would be almost as bothersome to FORCE the user to copy paste the file into the project file directory (or even copy paste it for them). But its still a possiblity.
Most VB projects work fine and people understand that you need to include all the files to get them to work so I don't see it as too much of a big deal if I did the same thing. I could even prevent small errors if I added a search routine that searched 1 folder level back and 1 forward find the file if it wasn't found where it was originally supposed to be. That might slow down the program a lot. It would be optional I guess.
@Randem: This is a relative path: ..\..\MyFile.txt
That means... from the current directory (or folder) go up (in the tree) two folders to find the file MyFile.txt. This is another relative path: .\SubFolder\MyFile.txt
Which means from the current folder go into the sub folder named SubFolder and file the file entitled MyFile.txt.
To anyone searching for this subject, I've answered this question in this thread: http://www.vbforums.com/showthread.php?t=365798
Joacim Andersson
And your point is....?
Simply that there is an API that you can use to find the relative path to any folder or file, which is what eyeRmonkey wanted to know.Quote:
Originally Posted by randem
.... and also that there is another API you can use to resolve (or expand, if you wish) the relative path to an absolute path.
Joacim Andersson,
Yes, but you need to follow the whole story not just an exerpt. It can't possibly find the relative path of a file on another computer.
...and I did... Please see the code I posted in the other thread.Quote:
Originally Posted by randem
Joacim Andersson,
No, not really there was a thread before that one about finding the relative path of a file from another computer... When moved to his computer (Project file).
Just read the first line of that post.
Let me expand on that... Why would you want to store the relative instead of the absolute path to anything? Well the answer would be that you might not know the absolute path when you want to store it. We all use App.Path to get the path to where our program is started from. But what if we actually install our app in a subfolder of the folder selected by the user during the installation progress? This is fairly common with application like a compiler for example. Some files are stored in the folder selected by the user but the compiler itself is installed in a Bin subfolder. So what should you then do if you need to read a file stored at the root of the installation? The answer is to use a relative path, something like "..\theFileIneedToCarryOn.dat".
So how would you reslove that path then? Read my reply in the other thread.
I may have missed a thread about "finding the relative path of a file from another computer".... But I've answered the question in this thread :)Quote:
Originally Posted by randem
Joacim Andersson,
That is already known. The part you keep ignoring is that when you move the relative path from one computer to another it may not be relative on that computer the way you think.
Joacim Andersson,,
Ok, you answered a question, so why direct it to me? I did not ask the question.
Sorry about that Randem, I didn't want to start an argument with you :).Quote:
Originally Posted by randem
However the relative path from a given path is always the same, if the file is not present at that path so be it. But the question asked here (and you debated this issue long before I wrote a reply) was how to find the relative path to a file or folder from a given absolute path, and maybe also how to resolve a relative path into an absolute path given a starting point.
The question wasn't if a file was present or not but how to create a relative path from two different starting points.
Joacim Andersson,
On thing cannot be relative to something that is not there. And I repeat Relativity can only be from an absolute.
Well, the question asked in this thread was: "How can I get a relative path to one thing from another path".
Sort of "I know that the relative path to 'c:\winnt\notepad.exe' from 'c:\winnt\system32' is '..\notepad.exe', but what code should I use to get that relative path?". That was the question asked and that is the question I answered (in the other thread). The other discussion might be of interest from a philosophical point of view but it doesn't answered the question.
I didn't mean to start an argument with you randem, and I hope we can end it in a friendly way right here. But there are uses for finding the relative path for a file from a giving absolute position. The code is useful, I don't think MS would have introduced the API if it wasn't...
There is no reason why relative paths cannot be relative to other relative paths, as long as they are resolved in the corrent order.
Likewise, there is absolutely no reason why a path is not relative if applied on a different computer. C:\Folder1\Folder2\..\.. is C:\ on any computer.
penagate,
Really??? And suppose you put the file on d:\ or d:\folder is it still relative to c:\?
Of course not. It is relative to the current folder. So if it was in D:\Folder1\Folder2 instead of C:\Folder1\Folder2, you would get D:\ instead of C:\.
penagate,
Then a relative path would not work there would it? It has to relate to an absolute. That is why you can't just move it anywhere and expect it to find the folders and files. Expecially if the folder does not exist where the file is moved too.
Right, let's take this example
I have my dev projects organised in the folder C:\penagate\stuff\Dev.
In my \Dev folder I have a project in its own folder, let's call it \DancingBadgers.
A project file in the DacingBadgers project references a component in \Dev\Common.
The path to the component, therefore, relative to DancingBadgers, is \..\Common\thing.dll. It resolves to C:\penagate\stuff\Dev\Common\thing.dll.
Now suppose I move everyhing out of the \stuff folder so that it is just C:\penagate\Dev. The relative path will still work, because it now resolves to C:\penagate\Dev\Common\thing.dll, which is correct.
Suppose I move it to my D:\ drive so that it is D:\Dev. The path now resolves to D:\Dev\Common\thing.dll. Still correct.
I'm afraid I really don't see what you're getting at :(
penagate,
That is assuming that the folder structure is already setup and exist. But that is not what started the convesation in the first place. If you move one of my projects to your computer, my relative paths would not be fould there and you could have the files on you computer.
I don't understand why you still discuss this matter. A path can't work regardless if it's a relative or an absolute path if the file doesn't exist there, that is of course true. But that doesn't mean relative paths is useful. I still use Office 2000 on my computer. That is installed in the "c:\Program Files\Microsoft Office" folder, however the applications aren't found in that folder, they reside in a subfolder named "Office". So the absolute path for WinWord.exe on my computer is "c:\Program Files\Microsoft Office\Office\WinWord.exe". However the templates used by Word is installed in another subfolder entitled "Templates", but still Word finds them. That must be because Word is using a relative path to access the templates (well, I know that Word stores the path to the templates in the Registry but that's beside the point).
If I would just move the Templates folder Word wouldn't be able to find them, but so would be the case even if an absolute path is used. So it doesn't matter if you use relative paths or not if you mess up the installation, but that wasn't what this thread was about.
Don't larger applications require that you set all of your folder/library/etc paths in an 'Options panel', i.e. another form specifically designed to keep track of relative/non relative paths.
Just a thought.