[RESOLVED] Store information within program

I'm makeing a program that users will be able to have run on start up. In this program I need to create temporary files in their My Pictures folder. Unfortunatly sometimes this folder does not exist or user's profile has changed and the Evironment.user is no longer accurate. So what I would like to do is have the program check to see if the My Pictures folder exsists. If it does... wonderful. If it doesn't I have the user choose a directory where the temporary files can be created. My question is, is there a way that I can take the users chosen directory and be able to use it again next time the program starts up? I would like to do this without creating another file in which I would store the information (i.e. create a text file with the directory path in it). The reason is because the people that use this program don't have privlages to write anywhere. So I would like have the chosen directory be stored in the program if it is possible.

Thanks in advance.

You can use settings in C# to store information pertaining to the application.
Take a look at http://msdn.microsoft.com/en-us/libr...69(VS.80).aspx

Why not write the temporary files in the proper location rather in the My pictures folder?

See Environment.GetFolderPath( SpecialFolder.ApplicationData );

Quote:

---

Originally Posted by Arjay

Why not write the temporary files in the proper location rather in the My pictures folder?

See Environment.GetFolderPath( SpecialFolder.ApplicationData );

---

Unfortunatly the users of this program do not have sufficient privlages to save files anywhere other than their documents. The reason I need to add this capability to my program is because the users name may have changed (ie. someone got married) so their log on info chaged but not how it is accessed in their my documents. I have no idea why my company would allow this but I don't care, I get paid at the end of the week regardless. Also It allows me to learn new things about programing. Hopefully that explained my needs for this a little better.

Quote:

---

Originally Posted by Shuja Ali

You can use settings in C# to store information pertaining to the application.
Take a look at http://msdn.microsoft.com/en-us/libr...69(VS.80).aspx

---

I tried doing it and what I would like to do is have a string in the settings that points to "C:\\Documents and Settings\\Environment.UserName\\My Documents\\My Pictures", but it doesn't work because it doesn't make "Environment.UserName" into the users user name. Is there any way to make this work.


Thanks for the help guys.

Quote:

---

Originally Posted by vandel212

Unfortunatly the users of this program do not have sufficient privlages to save files anywhere other than their documents. The reason I need to add this capability to my program is because the users name may have changed (ie. someone got married) so their log on info chaged but not how it is accessed in their my documents. I have no idea why my company would allow this but I don't care, I get paid at the end of the week regardless. Also It allows me to learn new things about programing. Hopefully that explained my needs for this a little better.

---

As a user, I would find it irritating to discover temporary files created by some application in the My Pictures folder. It seems surprising that a company would lock down the ApplicationData folder and break the functionality of many apps.

Check out http://msdn.microsoft.com/en-us/libr...istauac_topic6

and look at the section titled Per-User Application Settings Locations.

Quote:

---

Originally Posted by vandel212

I tried doing it and what I would like to do is have a string in the settings that points to "C:\\Documents and Settings\\Environment.UserName\\My Documents\\My Pictures", but it doesn't work because it doesn't make "Environment.UserName" into the users user name. Is there any way to make this work.


Thanks for the help guys.

---

Code:

---

string path = string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName);

---

Quote:

---

Originally Posted by eclipsed4utoo

Code:

---

string path = string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName);

---

---

I'm sorry I don't understand, is this supposed to do this a design time or am I supposed to do this a run time, because putting it in the settings at design time didn't work.

Quote:

---

Originally Posted by Arjay

As a user, I would find it irritating to discover temporary files created by some application in the My Pictures folder. It seems surprising that a company would lock down the ApplicationData folder and break the functionality of many apps.

---

Application Data would be a better place to save it, thanks for the tip. They didn't lock down anything in the users documents, so Application Data would still be a valid folder. Regardless I would still need to have settings to account for changed user names.

Quote:

---

Originally Posted by vandel212

I'm sorry I don't understand, is this supposed to do this a design time or am I supposed to do this a run time, because putting it in the settings at design time didn't work.

---

You do that at design time in code. When executed, it will give you the path with the current username.

Since you are going to using the Application Data folder, this isn't needed anymore.

Quote:

---

Originally Posted by eclipsed4utoo

You do that at design time in code. When executed, it will give you the path with the current username.

Since you are going to using the Application Data folder, this isn't needed anymore.

---

Why wouldn't it be needed the Application Data? It would still have to go to the user's specific folder in documents and settings.

Quote:

---

Originally Posted by vandel212

Why wouldn't it be needed the Application Data? It would still have to go to the user's specific folder in documents and settings.

---

if you use the built-in methods, you don't have to worry about it.

Code:

---

string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

---

This will return "C:\Documents and Settings\[username]\Application Data". So you don't need to worry about the user name. .Net will take care of that for you.

Quote:

---

Originally Posted by eclipsed4utoo

if you use the built-in methods, you don't have to worry about it.

Code:

---

string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

---

This will return "C:\Documents and Settings\[username]\Application Data". So you don't need to worry about the user name. .Net will take care of that for you.

---

Hey just like in post #3. :)

Quote:

---

Originally Posted by Arjay

Hey just like in post #3. :)

---

Yes....It seemed like he missed that post.

Quote:

---

Originally Posted by vandel212

I. My question is, is there a way that I can take the users chosen directory and be able to use it again next time the program starts up? I would like to do this without creating another file in which I would store the information (i.e. create a text file with the directory path in it). .

---

try writing the folder path in registry or config file corresponding to the current user.. each time when you start up try reading this file.

Quote:

---

Originally Posted by eclipsed4utoo

if you use the built-in methods, you don't have to worry about it.

Code:

---

string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

---

This will return "C:\Documents and Settings\[username]\Application Data". So you don't need to worry about the user name. .Net will take care of that for you.

---

I understand that .NET will get the user name for me but that is the problem. I've already run into this problem with the program I writing now. Let me do an example and you can tell me what I'm missing because I'm sure I'm missing something. I try to make it go to Environment.UserName, lets say their user name is jane.doe. Jane Doe gets married and changes her last name. Now her name is Jane Smith. Her username on the computer is now jane.smith, but the documents and settings folder for her is still under jane.doe. This is the problem because if I use Environment.UserName it will go to: "C:\Documents and Settings\jane.smith" which is not a valid folder. I know it is really strange that the user's documents and settings folder didn't change but I have no control over that, unfortunatly I have no choice but to work with it.

So is the way you mentioned before going to work?


Also this is what I tried for the settings stuff and I can't get it to work.

Code:

---

namespace Red_Lining_Application.Properties {
   
   
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "9.0.0.0")]
    internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {
       
        private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));
       
        public static Settings Default {
            get {
                return defaultInstance;
            }
        }
        string path = string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName); // I get an error trying to use Environment.Username.
        [global::System.Configuration.UserScopedSettingAttribute()]
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
        [global::System.Configuration.DefaultSettingValueAttribute(path)]
        public string UserPath {
            get {
                return ((string)(this["UserPath"]));
            }
            set {
                this["UserPath"] = value;
            }
        }
    }
}

---

even if I put in "using System;" it still throws an error because it is not a constant vaule. I don't think I completly understand what you meant by you use it in design time in the code. I went to Settings.designer.cs. thats where I'm supposed to go right?

Code:

---

namespace Red_Lining_Application.Properties {
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "9.0.0.0")]
    internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {
 
        private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));
 
        public static Settings Default {
            get {
                return defaultInstance;
            }
        }
        string path = string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName); // I get an error trying to use Environment.Username.
        [global::System.Configuration.UserScopedSettingAttribute()]
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
        [global::System.Configuration.DefaultSettingValueAttribute(path)]
        public string UserPath {
            get {
                return ((string)(this["UserPath"]));
            }
            set {
                this["UserPath"] = value;
            }
        }
    }
}

---

Dont do this in the Properties itself ! Do this where your code wants to read the UserPath
Simple instead of accessing the Properties

Code:

---

string userpath = Properties.Settings.Default.UserPath;
// do
string userpath =  string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName);

---

No need to have that code in the Properties. !!

Quote:

---

Originally Posted by JonnyPoet

Dont do this is the Properties itself ! Do this where your code wants to read the UserPath
Simple instead of accessing the Properties

Code:

---

string userpath = Properties.Settings.Default.UserPath;
// do
string userpath =  string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName);

---

No need to have that code in the Properties. !!

---

he can't use Environment.UserName in the path. The Environment.UserName can be different from the user name in the path(look at his example a couple of posts up).

Once thing you could do is get each subdirectory in the C:\Documents and Settings directory, then parse the string to see if that matches the first name of the current user(since you can't use the last name). I don't know how your company works, but at mine, I am the only user(other than administrator) on my PC. So in the C:\Documents and Settings directory on my PC, there are only two folders.

Quote:

---

Originally Posted by eclipsed4utoo

he can't use Environment.UserName in the path. The Environment.UserName can be different from the user name in the path(look at his example a couple of posts up).

---

I see. In that case I would try to find the folder by my program using an address written into the Properties.Settings.Default.DataPath, but if the name has changed and it cannot be found, then I simple would pop up a small Setup form where the user can input the new place where the file is located now. And storing that new location in the properties again.

Quote:

---

Originally Posted by JonnyPoet

I see. In that case I would try to find the folder by my program using an address written into the Properties.Settings.Default.DataPath, but if the name has changed and it cannot be found, then I simple would pop up a small Setup form where the user can input the new place where the file is located now. And storing that new location in the properties again.

---

or could use the FolderBrowseDialog and let the user choose what their user folder is.

Here you want to save data at system level and not at user level. Then you should not store data in any of user folders. You can designate some folder, on the root path of system-drive (or other drive). User should know where exactly that is stored. Provide the details in application itself (like 'Options'), or in documentation. If you are having deployment (setup), you can ask user where the data files should be stored.

You also save the location of data files in registry, so that you can refer from that location always. If user is changed, he/she can set the data-folder using 'Options' type of UI you may provide.

Quote:

---

Originally Posted by eclipsed4utoo

or could use the FolderBrowseDialog and let the user choose what their user folder is.

---

Yep but let the user the possibility to use FolderBrowser or textbox as well, as there maybe some connections when you have a network, where the Folderbrowser cannot show the directories of the server and you need to type it by hand..

Quote:

---

Originally Posted by Ajay Vijay

Here you want to save data at system level and not at user level. Then you should not store data in any of user folders. You can designate some folder, on the root path of system-drive (or other drive). ...

---

As much as I remembered he has told that this wasn't allowed by the firm which uses that program, or have I misduplicated what was written in an early post.

Quote:

---

Originally Posted by Ajay Vijay

Here you want to save data at system level and not at user level. Then you should not store data in any of user folders. You can designate some folder, on the root path of system-drive (or other drive). User should know where exactly that is stored. Provide the details in application itself (like 'Options'), or in documentation. If you are having deployment (setup), you can ask user where the data files should be stored.

You also save the location of data files in registry, so that you can refer from that location always. If user is changed, he/she can set the data-folder using 'Options' type of UI you may provide.

---

As he stated, the user's don't have the privileges to create files outside of their user folders. and it's not something he can change.

Quote:

---

Originally Posted by Shuja Ali

You can use settings in C# to store information pertaining to the application.
Take a look at http://msdn.microsoft.com/en-us/libr...69(VS.80).aspx

---

why not just use this? Then you don't have to worry about asking the user anything. the settings file is created in the Application Data folder for the current user. It doesn't matter what their user name is vs. what the user data folder's name is.

Quote:

---

Originally Posted by JonnyPoet

Dont do this in the Properties itself ! Do this where your code wants to read the UserPath
Simple instead of accessing the Properties

Code:

---

string userpath = Properties.Settings.Default.UserPath;
// do
string userpath =  string.Format(@"C:\Documents and Settings\{0}\My Documents\My Pictures", Environment.UserName);

---

No need to have that code in the Properties. !!

---

I understand what you are saying about using the Environment.UserName to find the appropriate path, but as I've explained in my last post this doesn't work 100% of the time in my situation. I've had my code setup simlar to that before I even started this thread and it blew up when the directory did not exist. Now I have my program look to see if the path exists and if it does not it makes the user locate their "My Documents" and from there it finds the Application Data folder. Then it needs to save the file path into the settings because if it didn't, it would ask the user to locate their my documents every time the program ran.

Quote:

---

Originally Posted by vandel212

.... it blew up when the directory did not exist. Now I have my program look to see if the path exists and if it does not it makes the user locate their "My Documents" and from there it finds the Application Data folder.

---

Then simple use a try -catch block and if you get an exception because the path doesn't exist you open the setup form and let the user choose his new path by that.
Ot use what eclipsed4utoo and Suhja Ali already suggested because thats possible in any case and doesn't need any username.

Just use the application data code that I posted in #3, check for the existence of the path (Directory.Exists) and if the path doesn't exist, create it (Directory.Create).

Note: this won't cover the case if a user has a name change (such as getting married); however, that would the responsibility of the network admin to properly migrate the user's settings in this case.

If the network admin doesn't migrate the settings, then your program should just recreate the default settings (by checking for existence of the file with File.Exists). There is no need to prompt the user for the old settings because most likely they won't know where to find them anyway (or a network admin may have wiped them out).

Quote:

---

Originally Posted by Arjay

Just use the application data code that I posted in #3, check for the existence of the path (Directory.Exists) and if the path doesn't exist, create it (Directory.Create).

Note: this won't cover the case if a user has a name change (such as getting married); however, that would the responsibility of the network admin to properly migrate the user's settings in this case.

If the network admin doesn't migrate the settings, then your program should just recreate the default settings (by checking for existence of the file with File.Exists). There is no need to prompt the user for the old settings because most likely they won't know where to find them anyway (or a network admin may have wiped them out).

---

I agree the network admin should migrate the settings, but I don't think that is going to happen anytime soon. Creating the directory is a good solution but the problem lies with that they might not have sufficient privliges to create that directory. So prompting the user for their my documents folder is the only solution I could think of. I thought about the whole user finding their name in the documents and settings as well and I figured that if they weren't familiar enough with computers they wouldn't know where to find it. However finding 'My Documents' is pretty basic, so I have them find their My Documents and then manipulate the string to get the user's username. Because when the Folder Browser Dialog box comes up, the My Documents is the second or third folder on the list by default, so it's hopefully easy for them to figure out.

I think I got this working so I appreciate the help thank you very much.

Quote:

---

Originally Posted by vandel212

I agree the network admin should migrate the settings, but I don't think that is going to happen anytime soon. Creating the directory is a good solution but the problem lies with that they might not have sufficient privliges to create that directory. So prompting the user for their my documents folder is the only solution I could think of. I thought about the whole user finding their name in the documents and settings as well and I figured that if they weren't familiar enough with computers they wouldn't know where to find it. However finding 'My Documents' is pretty basic, so I have them find their My Documents and then manipulate the string to get the user's username. Because when the Folder Browser Dialog box comes up, the My Documents is the second or third folder on the list by default, so it's hopefully easy for them to figure out.

I think I got this working so I appreciate the help thank you very much.

---

In my opinion, that is still a lot of work when there is an option available to do everything automatically without the user ever having to tell you anything.

But you got it work, so we have success.

Quote:

---

Originally Posted by vandel212

I agree the network admin should migrate the settings, but I don't think that is going to happen anytime soon. Creating the directory is a good solution but the problem lies with that they might not have sufficient privliges to create that directory.

---

There seems to be a disconnect here. You've already agreed that the ApplicationData directory is not locked down by the system admins, right? And since Windows allows programs to create files and directories underneath the ApplicationData directory, you are going to be good to go. There isn't any need to make this harder than it needs to be. IMO, prompting the user isn't a good solution because most users won't have any idea where to put these files and will become concerned when they see temporary files appear in their My Documents folders. Why not follow the Windows application compatibility guidelines and store the app data in the correct location?

Quote:

---

Originally Posted by Arjay

There seems to be a disconnect here. You've already agreed that the ApplicationData directory is not locked down by the system admins, right? And since Windows allows programs to create files and directories underneath the ApplicationData directory, you are going to be good to go. There isn't any need to make this harder than it needs to be. IMO, prompting the user isn't a good solution because most users won't have any idea where to put these files and will become concerned when they see temporary files appear in their My Documents folders. Why not follow the Windows application compatibility guidelines and store the app data in the correct location?

---

I see what you are saying, I'll have to check out if I can save to the users new account documents and settings folder. I looked at one of those examples where the person's name changed and it wouldn't work with Environment.UserName. The person did not have anything in the new user account's documents and settings folder, although I did not try to save anything to it. However, I did take your advice and the files are stored in application data now. It is not putting anything in the My Documents folder it's just taking "C:\Documents and settings\jane.smith\My Documents" and turing it into "C:\Documents and Settings\jane.smith\Application Data\Program Name" by removing 'My Documents' and replacing it with 'Application Data\Program Name'.

Quote:

---

Originally Posted by vandel212

I see what you are saying, I'll have to check out if I can save to the users new account documents and settings folder. I looked at one of those examples where the person's name changed and it wouldn't work with Environment.UserName. The person did not have anything in the new user account's documents and settings folder, although I did not try to save anything to it. However, I did take your advice and the files are stored in application data now. It is not putting anything in the My Documents folder it's just taking "C:\Documents and settings\jane.smith\My Documents" and turing it into "C:\Documents and Settings\jane.smith\Application Data\Program Name" by removing 'My Documents' and replacing it with 'Application Data\Program Name'.

---

and that's what it's suppose to do. Using this method means that you don't have to care about the user name. .Net will get the "Documents and Settings" directory that their Windows account is using, so you don't need to worry about a user name changing.

What I suggested doesn't cover the user change scenario, but typically this is a system admin function - in that, a sys admin is responsible for migrating user settings and documents over to the new user account.

Programs are usually not required to deal with that, unless the spec explicitly states that they do (and even then I would discuss with the pm whether you want to try to solve a problem that really can't be cleanly solved). If a sys admin does it, they know the old user name, they know the new user name, and can easily migrate all the documents and settings providing you following the rules on where to put application data and user data.

Quote:

---

Originally Posted by Arjay

Programs are usually not required to deal with that, unless the spec explicitly states that they do (and even then I would discuss with the pm whether you want to try to solve a problem that really can't be cleanly solved). If a sys admin does it, they know the old user name, they know the new user name, and can easily migrate all the documents and settings providing you following the rules on where to put application data and user data.

---

Well this program is set up to make sure that the Environment.UserName will work properly and it will for 99% of the users. So I tried to make it as user friendly as possible so that they have to locate their 'My Documents' once. I appricate all the help. Thank you very much.

Only user data goes in My Documents, if you are putting application data (such as temporary files or settings), it doesn't belong there. Application data belongs in the 'Application Data' folder which can be retrieved as mentioned earlier.

Hopefully that clears up any confusion.