Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Changing Paths...
#1
How would I make it to where in my sprite editor, the user can still change the path to what they have their sprites and stuff in, yet my program can still load it's necessary files?
Reply
#2
Maybe these concepts may be useful for what you wanna do:

http://faq.qbasicnews.com/?blast=RelativePaths

Tell me if they're, and we can talk about your problem more closely.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#3
MEGAMAN,

If I understand the problem correctly:
1) You want to know and save the full directory path (drive and directory) of where your program and it's files reside.
2) Then you want to change to a path specified by the user to reference some sprites files.

Ok. Normally I would use functions from a library to get the drive and directory where my program is at. Without these functions, you would have to do SHELL "DIR /AD >DIRTEMP". I used /AD because it makes the list shorter. Now you would open and read DIRTEMP looking for a line containing " Directory of ". Immediately after " Directory of " will come the drive and path where your program is being executed from.
Example " Directory of C:\megaprgs"
You now can save the drive and path of your program.
All this is at done at the beginning of the program.

All your references (opens) to your programs files must use the above saved drive and path as a prefix.

Now you can do a CHDIR to the usr's directory to process his files.

At thr end (or any error exit) of your program, you should do a CHDIR back to your original saved drive and path.

Note: If you use long directory names, I'm not sure that the CHDIR command is going to work. Hopefully you don't have this problem.
*****
Reply
#4
As I explain in the post above, there is no need to change directories from within your programs. You can always make use of relative paths. That way, your .EXE will always be in ".".

To save stuff in another way, use paths, for example:

Code:
OPEN "..\..\..\game\mygfx.gfx" FOR BINARY AS #1

And when you need stuff from your program directory, just...

Code:
OPEN "stuff.stf" FOR BINARY AS #1

You mention the user changing the path where he or she wants to save his or her stuff. The only thing you have to do is storing it in a string, and when saving, you just:

Code:
OPEN userpath$+filename$ FOR BINARY AS #1

For example, if the user has his or her game at "C:\MYGAMES\PLATTO1\", and the file is called "BACKDROP.GFX", the file open is "C:\MYGAMES\PLATTO1\BACKDROP.GFX". Note that if userpath$ is empty, stuff will be saved to the current directory (your .EXE's directory). Also note that userpath$ should end with a "/" if it is not empty.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#5
that his program is in the currend directory? If that assumption is valid, he could also do

SHELL "CD >DIRECT.TXT"

and read the current disk and directory from there. Regardless of where the program is and what directory you're in when you run the program, you can find out from the DOS environment copy what the fully qualified name of the currently running program is and extract the path to it from that name. NAME.FUN inside of

http://www.geocities.com/gstumpff/utils.zip

returns that fully-qualified file name.
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
#6
Here's one... how do I make the program figure out what directory it's already in? If I can get that... everything else should be cake...
Reply
#7
You're right, Glenn. The shell "cd>direct.txt" is much simpler than using the "dir".
*****
Reply
#8
did you read my post? :) (The function (PNAME$) in NAME.FUN returns the full name of the currently running program. For example, if you're in C:\WINDOWS and run PROGRAM.EXE, and that program is actually in C:\QB, if you do

PROGNAME$ = PNAME$

PROGNAME$ will be "C:\QB\PROGRAM.EXE". You can extract the "C:\QB" from that. (Start at the right, use MID$, and look for a "\".))


Quote:Here's one... how do I make the program figure out what directory it's already in? If I can get that... everything else should be cake...
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
#9
Quote:Here's one... how do I make the program figure out what directory it's already in? If I can get that... everything else should be cake...

Making an EXE does that for you.
;*)
y smiley is 24 bit.
[Image: anya2.jpg]

Genso's Junkyard:
http://rel.betterwebber.com/
Reply
#10
(DOS may know where the program is, but I think he wants to know how to make his program determine what DOS knows.)

Quote:
Megaman Wrote:Here's one... how do I make the program figure out what directory it's already in? If I can get that... everything else should be cake...

Making an EXE does that for you.
;*)
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)