saving user entered fields to apply later [RESOLVED...Thanks!]

[chadwickmurky]

I have a bunch of different windows forms in my application, with controls on a couple different forms. Users can enter options in all of these controls and forms and everything. I want to be able to save these options so the user can get them back. In doing this I'd like to provide a couple different "settings groups". The user could pick from a drop down box which group of his/hers that they wanted, and the settings they had set for that group will be inserted back into the text fields, checkboxes, etc. Any suggestions?

[wossname]

I would use Binary Serialisation. Set up some structures or classes to hold the data and give them all the Serializable() attribute.

Then open a filestream, serialize the data to it and that's it. Then reverse the process to get the data back from the file.

[chadwickmurky]

phew! that's a little out of my league i think.. haha.. i don't want you to write the code for me or anything, but do you know of anywhere on the internet or anything where i can get an example of how this works? i've just never done anything like that before. thanks for the reply!

[Grunt]

why would you need to serialize? You could just use streamwriter to write the data, and use streamreader when you want to add that data back.

[Shaggy Hiker]

All of this stuff about streamreaders and serialization assumes that you want to retain the information between uses of the program. You didn't actually say that, so I'm not sure if it is true.

Let's start with the simple case (no serialization). There is certainly a best way to do this, as I am finding out be experience: make use of the OO nature of .NET.

You either want to have a single class that holds all the information you need, or multiple classes (one per form) to hold the information. Originally (like in VB6), I might have used globals to hold the information, but classes are a better way to go.

Say you have something like this:

Public Class designatedHolder
 public int1 as integer
 public string1 as string
 
End Class

I would make the members public in this case, even though this violates the spirit of OO. Put in one member variable for each item in the form. Make an instance of the class on startup, and in the form load event, take the info from the class and put it in the form. When the form closes, put the data from the form into the class.

The advantage to this is that you can add functions to the class to do a variety of management things. You could add a clear function to erase all the variables. You could add a copy function that would return a copy of the class so that you could quickly make new states and use them in the form without corrupting a separate copy. Depending on your needs, you could also add a function to do intermediate calculations.

One thing you mention is the settings. You could add a function to the class such that the class will be set to the settings listed in the list box. Pass a setting name to the function, and have the function set the variables as needed.

This encapsulates all the options and settings into a class with all the functions needed to manipulate the data. A bit tedious to set up, but once done, it becomes really easy to maintain, and that alone justifies the effort.

Now, as to all that saving foolishness those others mentioned, if you want to persist the information about the states between runs of the program (so that the user can quit the program, then start it up again and it will remain in the same state they left it), there are three options:

1)Save it all to a database. If you are not currently using a database, I think it would be unwise to add all that overhead just to save the data.

2)Write it all to a text file (that's one use of the streamreader/streamwriter type of idea). This is quick and insecure, but could be added to the class as a SaveData() / ReadData() pair of functions.

3) Take wossy's suggestion. Serializing the data would require little effort, and would result in a file like option 2, but the file would be both smaller, and semi-secure since it would probably be illegible to a textreader. In general, I would favor this option if you have several things to save (it sounds like you do), and those things are not simply text. I have used option 2 for a really simple thing, but this is worth looking into, as well.

[chadwickmurky]

Wow, thanks a lot everyone this helps a lot. I was looking into the serialization more and it seems like I might do that. I actually really don't need to save the settings in between uses, however I think it could be good to try something I haven't done before, and maybe it would add some functionality that someone might like. Thanks for the help guys.

[wossname]

why would you need to serialize? You could just use streamwriter to write the data, and use streamreader when you want to add that data back.

Serialising does use streams. Plus you can load the whole lot in one operation. Plus binary Serialization is fast and efficient.

[wossname]

phew! that's a little out of my league i think.. haha.. i don't want you to write the code for me or anything, but do you know of anywhere on the internet or anything where i can get an example of how this works? i've just never done anything like that before. thanks for the reply!

Ill throw together a quick sample for you so you can see how its done...

[wossname]

OK.

I started it and got quite involved so I have decided to polish it up a bit and bung it in the CODEBANK forum.

If you find it useful please gimme a rating

http://www.vbforums.com/showthread.php?p=1928364