[RESOLVED] Getting the path to a file

Is there is way to get the path of a file that is not in the App.Path?

I have a folder that contains other folders that contain sub projects for each component of the main project. A file is in the root folder of the project but each sub project requires access to that file. Normally, if the file was in the same folder as the project I would simply use App.Path.

Open App.Path & "\some folder\some other folder\file.txt"

My question is how can I access the file without hard coding it's path in each of the sub projects?

Not enough info...

What are these sub projects? Are they started from the main app?

If you are launching them from your main project you can pass the path as part of the command line
If that is not possible there is always the option of using an INI file or a Reg entry. I generally try to stay away from the reg entries and go with an INI file instead.

Use a .ini file or registry key?

These days using App.Path can cause problems and has been against the advice given by Microsoft since W2K, I believe.

No. Each app in a sub folder is launched separately. They all use the same file however. Why would an INI solve the problem; it's just a file

Why would App.Path cause problems? Been using it for years; never a problem

I think you need to explain the 'problem' further.

Quote:

---

Originally Posted by jmsrickland

Why would App.Path cause problems? Been using it for years; never a problem

---

In W7 (for example) you don't have write access to C:\Program Files

Speaking of a registry entry. How does the registry get the info? Since the file cannot be accessed directory by any of the apps (without using a hard coded path) then none of the apps can load the registry so how does the path get in the registry? Another problem is that this will run on other peoples computers so how would they get the info in the registry

Quote:

---

Originally Posted by Doogle

I think you need to explain the 'problem' further.

---

You mean I didn't explain it good enough?

There are three apps. Each app is in a different folder. Each app needs access to this common file. What more can I explain

Quote:

---

Originally Posted by Doogle

In W7 (for example) you don't have write access to C:\Program Files

---

Fine. I never use C:\Program Files anyway. I never use C: either for anything. So give me another reason why App.Path causes problems

Quote:

---

Originally Posted by Doogle

In W7 (for example) you don't have write access to C:\Program Files

---

How then do programs get into c:\Program Files. If you don't have write access then who or what puts them in there in the first place

Looking at your original post and combining that with information from Posts #8 and #9 helps, but I'm still not sure what you're asking for. What do you mean by a 'common file' in the context of the Apps running on other computers? (e.g. a Network share?)

The installer has write access to program files. Your program will not have access unless the user has turned off the UAC which is not recommended.

Never hard code paths into your program. Use INI file or reg entries or some other method that does not require rebuilding the exe to change

Ideally you should use the Special Folder for AppData or MyDocuments for your files depending on what they are. Assuming of course they are to be local.

In the case of a network share then I would say use an ini file

Quote:

---

Originally Posted by DataMiser

The installer has write access to program files. Your program will not have access unless the user has turned off the UAC which is not recommended.

Never hard code paths into your program. Use INI file or reg entries or some other method that does not require rebuilding the exe to change

Ideally you should use the Special Folder for AppData or MyDocuments for your files depending on what they are.

---

I will ask again

1) How using an INI help? An INI is just a file so the same problem exists

2) Registry. How would I or any one get the info in the registry?

Why doesn't each vb program do a drive and recursive folder search to locate this specific file....i'm assuming this file is unique in name, or so i would hope, so each program can find it with fileexists. Once found, each app saves that path wheneverit needs to access it. Am i missing the obvious?

Quote:

---

Originally Posted by Doogle

Looking at your original post and combining that with information from Posts #8 and #9 helps, but I'm still not sure what you're asking for. What do you mean by a 'common file' in the context of the Apps running on other computers? (e.g. a Network share?)

---

I cannot understand why my question is such a mystery

I have three applications. Each application is in a different folder. Each application needs access to one file (a common file to the three applications). Since the file is not is any of the three folders when the applications are then how can each application get access to this file without hard coding the path that that file.

You and DM have said use an INI. But an INI is just a file so what good will that do?

Also, I have been told to use the registry. I ask, how do I or any person using this project get the info in the registry

Quote:

---

1) How using an INI help? An INI is just a file so the same problem exists

---

No same problem does not exist.
You place the INI file somewhere that your app can find it then you read the values from that ini file and use them in your program. Ideally the INI file should be in the special folder for application data

Quote:

---

2) Registry. How would I or any one get the info in the registry?

---

You use the GetSetting and SaveSetting functions in VB, or use use API to access the registry

Quote:

---

Originally Posted by SamOscarBrown

Why doesn't each vb program do a drive and recursive folder search to locate this specific file....i'm assuming this file is unique in name, or so i would hope, so each program can find it with fileexists. Once found, each app saves that path wheneverit needs to access it. Am i missing the obvious?

---

OK, how to I do that

Quote:

---

Originally Posted by DataMiser

No same problem does not exist. You place the INI file somewhere that your app can find it then you read the values from that ini file and use them in your program. Ideally the INI file should be in the special folder for application data

---

That's the problem, DM, you say place the INI somewhere that your app can find. Well then, why an INI then? Why not just the file I am referring to. place it somewhere that the apps can find. Where? I have no idea when this project is running on someone else's computer where that somewhere will be.

Typically when I create a program I almost always use an INI file.
This file is usually created by the program when it is first ran and populated with default values. In some cases where the end user knows his/her way around a computer I will simply instruct them as to how to edit the INI file for their system, typically this would be a connection string and/or a network path to a file. In other cases I will create forms within the program for them to enter or browse and write the new entries into the ini file.

It is all pretty basic and should always be used rather than ever hard coding anything. Prior to Windows Vista every app I had written used an INI file and defaulted to App.Path. These apps still worked under Vista and Windows 7 so long as the user installs to their user folder or the public folder but now on newer apps the ini file gets written to the application data folder or common data folder if it is to be used by more than one user on the given pc

Quote:

---

Originally Posted by jmsrickland

That's the problem, DM, you say place the INI somewhere that your app can find. Well then, why an INI then? Why not just the file I am referring to. place it somewhere that the apps can find. Where? I have no idea when this project is running on someone else's computer where that somewhere will be.

---

Is it really that hard to understand? You place the INI file on the target PC where the App can find it. For example the appdata folder. In that INI file you have an entry that points to the data file you want to share. This INI file would be for the app not for all of the apps just that one and it will contain the path/filename to your shared file. The shared file may be on a mapped network drive or a UNC path, may be different on different PCS or whatever but the INI file will always be in the same place with the same name and you will always be able to find it and as a result get the path to your data file.

Same with the registry entry you can always locate your entry and read its value.

Hang on a minute, these applications are not running on the same PC (see Post#8) so unless the 'common file' is on a Network Share which all apps can see, then there is a problem. Under these circumstances the Registry option is not viable.

If each App opened 'App.ini' and 'App.ini' contained

Code:

---

[APPDATA]
CommonFile = H:\TheApps\commonData.txt

---

where 'H' is the network share and TheApps\commonData.txt is the file then the problem is solved. The App just reads the .ini APPDATA Section and gets the path from the 'CommonFile' entry, opens and reads it.(GetPrivateProfileString API)

If there's no possibility of a Network Share (e.g. the Apps are running over the Internet) then the data contained in the 'Common File' needs to be 'sent' to the apps in some way.

There would still be no problem using the registry though I would use an INI file the result would be the same the only difference is that it could be possible to have all the apps share the same ini file [or not as desired] where the registry option would require an entry for each pc and if using the VB methods an entry for each user since the VB methods save to the current user section of the registry.

In any case you can use either method to store and retrieve the path and filename to your data file whether it be a single user on one pc, several users on same pc or several users on several pcs sharing a network data file or each with their own data file

Look at the picture below

My question is this.

In the folder called 'Data' are files.

How can the applications in folders App1, App2, and App3 get access to a file or files in folder Data without hard coding the path the those files?

You say use an INI but that wont work because the INI have to be somewhere. My problem is then how do the Apps know where somewhere is without hard coding somewhere?

If the files in folder Data where in each folder App1, App2, and App3 I would use this:

App.Path & "\Data\File1.txt"

But I can't do that

Now don't tell me to use an INI because it's the same problem as the apps would need a hard coded path to the INI file.

If I use the registry then HOW do I get the info into the registry and HOW would a person using this on his PC get the info in his registry?

Trying hard not to laugh here. 24 posts and still a game of "Who's On First?" going on!

From your image in the last post it appears you want to use relative paths. But I'm probably wrong since that would be such an obvious answer. Just in case, consider the example:

Code:

---

Option Explicit

Private Sub Main()
    Dim Path As String
    Dim F As Integer

    Path = App.Path & "\..\Data"
    On Error Resume Next
    GetAttr Path
    If Err Then MkDir Path
    On Error GoTo 0

    F = FreeFile(0)
    Open Path & "\Data.txt" For Output As #F
    Print #F, "Some data"
    Close #F

    MsgBox "Complete"
End Sub

---

Edit:

The usual caveats apply in bizarre cases where App.Path is a drive's root directory. Shouldn't happen here though because your image shows all programs in their own subfolders.

Given the exact structure you've specified and given that App.Path for App1 is 'DISK:\MainProject\App1' (where DISK is, for example, 'C') then.

Code:

---

strUpALevel = Mid$(App.Path, 1, InStrRev(App.Path,"\")
strDataFolder= strUpALevel & "Data"

---

strUpALevel would be 'DISK:\Main Project\'
and
strDataFolder would be 'DISK:\Main Project\Data'

I can't see any way of not hard coding 'Data'

EDIT: Now I've read Dilettante's post I think I can

EDIT1: I'm still confused about App1, 2 and 3 running on different machines unless that directory structure exists on a network share which OP has not confirmed

App.Path & ".\Data\File1.txt"

EDIT: My bad. I thought you could use dot notation as described above. Well, maybe you can, but not as I illustrated (as my failed test just revealed!)

Quote:

---

Now don't tell me to use an INI because it's the same problem as the apps would need a hard coded path to the INI file.

---

Then I will stop trying to help you understand how to properly use an INi file.
No you don't need a hard coded path. You never need a hard coded path for anything and you should never use one. Look up Special folders

Quote:

---

If I use the registry then HOW do I get the info into the registry and HOW would a person using this on his PC get the info in his registry?

---

As I said before SaveSetting and GetSetting are the VB methods to read and write data from/to the current user section of the registry.

As to the relative path mentioned above that would not work under windows Vista and newer if the program were installed under program files due to read only permissions.

The answers have been given but not accepted so I am going to unsubscribe from this thread at this point.

Quote:

---

Originally Posted by DataMiser

As to the relative path mentioned above that would not work under windows Vista and newer if the program were installed under program files due to read only permissions.

---

That's actually a mistaken impression people have. Program Files should be considered a read-only location even as far back as Win95.

Win9x basically had no security even when logons were used so when "rustic cousins" finally move to WinXP they rely on things like Simple File Sharing, AppCompat, and giving everybody Administrator accounts to simulate the insecure world of Win9x. That's why XP was produced in the first place, essentially it is Win2K with a few new things plus a bunch of ameliorations for home users coming from Win9x.

But Program Files should still be read-only for Standard Users on WinXP and treated as such even on Win95.


My guess is that in this case these programs are never installed anyway. They are probably just tools for personal use and may even be left in the original Project folders next to the source code.

There's Mort, Elvis, and Einstein, and then there's Rube.

The only way that enters my mind for this to work is to put folder 'Data' in a fixed location, like C: which I don't really want to do. Then each application has hard coded path to that folder: "C:\Data".

In post #26 by doogle, I can see how I can make that work for me but that wont work for someone else if they put this project in an entirely different location on their computer.

I can't have an INI like DM suggested. I can't use the registry like DM suggested or anyone else suggested. In order for these methods to work you still have to know the exact path to the Data folder. You still have to know the exact path to where the INI file is. Yes, I can use the registry for me only because I know where this project is but, again I ask, how would another person know how to put this info in the registry. DM said to use VB's SaveSetting and GetSetting methods. But am I not still hard coding paths to load into the registry? It won't work.

The technique in post #25 should work fine. It is intended for just such a case as you showed in your folder structure image.

However since you've made it clear you plan to deploy this to other machines then I'd go back to suggesting the same things others have already and that you seem to reject. Do not "install" programs into random folders, they belong in Program Files under normal circumstances. And of course that implies that you place the data elsewhere, generally under CommonAppData.

i got answer your solution easy method but the way i do it is for login user names when ids are logged in success tool creates a folder for that username automaticly and so on and all data for that user are stored in his own folder , so similar trick will get you started i dont think this is gone be hard code you just need to create a folder for each server and find all data in each for each server this will do
it:p


so do it opposite way if servera is open then check if folder is there if not make it and put all its data there and extract whats needed from that folder il se how u can fix if not il post mine
if u think this is gone help il post my code , how it finds the correct folder + what file you want to get from that folder:p:p:p:p:p:p:p

@dilettante

I didn't see your post #25.

Yes, your code works exactly what I need. Thank you very much.

BTW: I'm not deploying this or installing this on another computer. I will give the project to others if they want it and they can do with it as they please. I didn't know how to do what you posted so I had to hard code the path to the 'Data' folder and realized this wont work for someone else

I was just looking for a way that the code will run the same on their computer as it does on mine as far as getting access to this file from the three applications.

Glad it helped.

I guess a picture can be worth 100 posts. ;)

BTW:

As long as the programs always run with the current directory as the App.Path you can use a path relative to CD:

Code:

---

    Path = "..\Data"

---

@ladoo

Your client/server and my client/server work differently. My server does not create user folders or data on the fly. That is not the responsibility of the server. The server only checks for certain files in the user's folders.

I have seen your code. You server makes a folder for a user when a user signs-in, mine doesn't. The user folders are already made in advanced and are populated with files in advanced.

Quote:

---

Originally Posted by dilettante

BTW:

As long as the programs always run with the current directory as the App.Path you can use a path relative to CD:

Code:

---

    Path = "..\Data"

---

---

What happens if 'Data' is also a folder in another project unrelated to this project?

?

I don't see how that's a factor. Have you never used relative paths before?

The ".." means "the directory up one level from here" so there is no way it could wander off to some random location.

OK. I thought it would just find the first occurance of a folder named 'Data' under the CD

So, actually, Path = "..\Data" is better than Path = App..Path & "\..Data"

Quote:

---

Originally Posted by dilettante

Trying hard not to laugh here. 24 posts and still a game of "Who's On First?" going on!

---

Actually, it's your fault. If you had responded earlier there wouldn't have been 24 posts:)

Quote:

---

Originally Posted by jmsrickland

So, actually, Path = "..\Data" is better than Path = App..Path & "\..Data"

---

Not really, but it works in the degenerate case where CD = App.Path. When that isn't true everything falls apart!

Note that even using File Open or File Save common dialogs can change the CD of a program while it runs.

So if you mean App.Path always use App.Path.

Quote:

---

Originally Posted by jmsrickland

Actually, it's your fault. If you had responded earlier there wouldn't have been 24 posts:)

---

I had no idea what you wanted until you drew a picture.

Quote:

---

Originally Posted by dilettante

Not really, but it works in the degenerate case where CD = App.Path. When that isn't true everything falls apart!

Note that even using File Open or File Save common dialogs can change the CD of a program while it runs.

So if you mean App.Path always use App.Path.

---

If I use Path = App.Path & "..\Data"

and then later use a common dialogue to find a file somewhere else will that screw up Path?

No.

App.Path never changes.

OK, thanks. I changed it back to Path = App.Path & "..\Data"

HAHA This thread is awsome! I think you (jmsrickland) already the answer of your question. Simple, use "App.Path".

No, Max. I only knew of App.Path & "\Data\Myfile.text" but that would not have worked. What I didn't know was App.Path & "..\Data" which dilettante posted.

Ah, ok. Well I'm glad your happy with what dilettante told you. :)

Quote:

---

Is there is way to get the path of a file that is not in the App.Path?

---

while this appears to be resolved, the searchtreeforfile API appears to fulfill the original request