relative paths

[na_th_an]

I read that tutorial on RelativePaths, and I consider it to be very poorly written.

Uh ... thanks :-|

It was a reply to someone's problem, but it got posted into the FAQ.

Care to tell me why you think it's poorly written? It's not a tutorial, mind you. Plus the person it was directed to had a basic knowledge of how directories are organized on disk. I've re-read it and I don't find anything that's poorly written or incorrect, sorry.

[Anonymous]

change "../" to "a directory above"

that tute IS a little hard to understand but meh...

[Moneo]

I read that tutorial on RelativePaths, and I consider it to be very poorly written.

Uh ... thanks :-|

It was a reply to someone's problem, but it got posted into the FAQ.

Care to tell me why you think it's poorly written? It's not a tutorial, mind you. Plus the person it was directed to had a basic knowledge of how directories are organized on disk. I've re-read it and I don't find anything that's poorly written or incorrect, sorry.

Amigo Nathan,

You're right, it's a FAQ, and not a tutorial. If you wrote this, I'm sorry to tell you that IMHO it is poorly written because I can't understand it.

However, as you said, it was directed at a particular person. If this person understood it and was able to solve his problem, then the explanation was a success. But, I feel that if it's going to remain there, it should be enhanced to make it clearer for the general audience.
*****

[Antoni Gual]

Well, about jony_basic's problem:

Perhaps the problem is not in the way you implement relative paths, the problem can be in the way you run the program. If you click on the program in the Windows explorer, the path is not changed to the program's folder, so you are running it from another place: the relative paths will not work.

You should edit the shortcuts of all windows programs using relative paths to make them use the program's folder as the start folder. This way everything will work.

[Ralph]

Antoni...and whoever else:

This sounds interesting, but I don't understand what this is all about. I'll try to clarify where I'm at.

Say I have the path and program C:\BASICS\QB45\QB.exe
And, say that I have the extension .bas assigned to the program QB.exe. In Windows, if I double click on the file Sprites.bas, the program QB.exe will be started up, and the program Sprites.bas will load in QB.

If I right click on the file Sprites.bas, and select Shortcut, I will end up with an icon that contains the necessary paths to run Sprites.bas within QB.exe.

Now, besides the above, if I know that the path to Sprites.bas happens to be C:\BASICS\QB45\progs\Sprites.bas, are you stating that the "relative path" to Sprites.bas is that path that, starting from the "mother" program, QB.exe, ends in Sprites.bas, such as ..\Sprites.bas for our present case? If so, how would I use the relative address? Obviously, if I embed that address in a program, the Sprites.bas would have to be located in the same exact relative address in any user's computer, which, I believe, is the opposite from what is wanted.

Am I missing the point, all together?

[Anonymous]

this is how windows will handle it

- Change to working directory (in shortcut info)
- Calculate relative path to executable
- Pass any command line args to the executable at that path; execute.

now, at this point, your exe is running (say qb.exe) the cwd (current working directory) is still whatever the "working folder" is. if it's blank, then its whatever windows happened to end on with any other operation.

anyways. lets say for example your working dir was c:\ and you passed the shortcut c:\windows\desktop\eheh.bas. qb is in c:\qb45

in this case windows, using the procedure i said above, will do this:

- Change to c:\
- relative_path_to_exe = "qb45\"
- execute relative_path_to_exe\qb.exe "c:\windows\dekstop\eheh.bas"

so, now, when you're in qb, if you hit open to open a file, you're in "c:\", not in "c:\windows\desktop\", which might seem more intuitive to some people

[na_th_an]

The thing was about someone who posted a program that had to be installed in C:\WHATEVER 'cause it included some "OPEN "C:\WHATEVER\FILE.EXT" FOR BINARY AS #1". I replied explaining to him that by no means a program should make you have to install it in some fixed place.

The post explained how "OPEN "FILE.EXT" FOR BINARY AS #1" will open FILE.EXT if it is in the very path where the executable lies, provided you didn't change the current path with a CHDIR command within the program.

The problem QBers have with paths is that, in most cases, they fail to open the command line interpreter and understand how it works - instead they do double clickies and create shortcuts. Of course, then they have no clue where their programs are looking for the files. I can't remember now, but I think to remember that the QB IDE doesn't have an option in the fashion of "set working directory" as the VB IDE has, so the solution has to be worked out:

When I used QB, I had QB.EXE added to the PATH environment variable. That means that when I wanted to start a project, I opened a command line interpreter, I navigated to my development folder, I created a new folder, and, from that new folder, I ran QB.EXE - no probs as QB was in the PATH environment variable. That guaranteed that, both in the IDE and then running the compiled EXE, my files would be correctly located and accesible, devoidening the necessity of using fixed paths in the code.

I guess that someone found it interesting so he or she added it to the FAQ. The problem is, it is completely out of context. Just look at how it starts: it's clearly a reply

[Moneo]

Great, Nathan, that makes sense.

Somebody should append your post to the FAQ item.
*****

[Antoni Gual]

Now, besides the above, if I know that the path to Sprites.bas happens to be C:\BASICS\QB45\progs\Sprites.bas, are you stating that the "relative path" to Sprites.bas is that path that, starting from the "mother" program, QB.exe, ends in Sprites.bas, such as ..\Sprites.bas for our present case? If so, how would I use the relative address? Obviously, if I embed that address in a program, the Sprites.bas would have to be located in the same exact relative address in any user's computer, which, I believe, is the opposite from what is wanted.

Am I missing the point, all together?

The relative paths you can embed in your program are those to the auxiliar files your program requires (sprites, init files, databases, texts) . They will always be located in your program folder or in subfolders of it.
The path to QB can¡t be coded in a program and it will be different for every user. It's up to the user to have QB in the path...

[jony_basic]

It seems this post took on a life of it's own. :???:
I appologize for my long absence, I've been working hard on "The Sword of Arisan".
well I think I see where the problem is, I am starting QB from "C:\qb45\qb.exe".
when I should be starting a QB.exe from the path of my project?
I did try this, it appeared to work at first. But when I moved the project folder to the desktop, it had the ever present missing files error.
I even wrote an error handling routine because it happens so often.
I'm sure I'm missing something, is there a chance some one can walk me through it?