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?
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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.
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
Why would App.Path cause problems? Been using it for years; never a problem
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
Last edited by jmsrickland; Mar 6th, 2013 at 12:30 PM.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
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?
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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?
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
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
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
Last edited by DataMiser; Mar 6th, 2013 at 12:58 PM.
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
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?
Last edited by jmsrickland; Mar 6th, 2013 at 01:27 PM.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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.
Last edited by dilettante; Mar 6th, 2013 at 01:57 PM.
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
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!)
Last edited by ColinE66; Mar 6th, 2013 at 02:04 PM.
If you don't know where you're going, any road will take you there...
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
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.
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.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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.
Last edited by dilettante; Mar 6th, 2013 at 03:08 PM.
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
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
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.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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?
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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"
Last edited by jmsrickland; Mar 6th, 2013 at 04:30 PM.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
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
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.