I think what you mean is saving the "session data" of the application, so when the user closes the main window, some required data is saved to disk, and when a user starts the application again, things should be restored to the state of of the time when the user was working for the last time. In other words, this is about having the persistent state of the application. Is that so?
To start with, I would recommend to make this application state persistent data really comprehensive. Otherwise the functionality usually confuses the user. The users say: "OK, the items in this list box are restored, but I also changed the size of the window and moved it up; why this is not restored? And I also changed the selections, where they are. And, more importantly, how to tell what is supposed to persist, and what not?". Every inconsistency in what you decide to persist may annoy the user. That's why, if you even go this way, try to persist all the
application state, everything which your application controls and even more.
Now, what you need to know first, is where to store the data. The directory cannot be working directory or your executable directory (which is supposed to be read-only in general case), so you need to use one of these methods:
http://msdn.microsoft.com/en-us/library/system.environment.getfolderpath.aspx[
^],
see also:
http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx[
^].
Most likely, you would need to use
System.Environment.SpecialFolder.LocalApplicationData, but it depends on how you support user accounts.
Now, how to create and persist the data. First of all, you need to create the
data model of the application state diagram. This should be a set of the pure-data classes, not directly related to UI and not related to persistence. On startup (when a main form or a main window is created), you need to read the data and
populate the UI with it. On closing of the application, you need to store the data. This link code should be aware of both UI and data model, but UI should not be aware of data model, and the data model should not be aware of data. (This is called
loose coupling, please see:
http://en.wikipedia.org/wiki/Loose_coupling[
^].)
And the persistent mechanism should be
agnostic of the particular data schema (metadata), to be re-usable and reliable. To get such thing, you need to learn about
serialization:
http://en.wikipedia.org/wiki/Serialization#.NET_Framework[
^],
http://msdn.microsoft.com/en-us/library/ms233843.aspx[
^].
The good serialization code should be able to store/restore any arbitrary
object graph and be
non-intrusive to the data model. It means that the data model should be developed in a way agnostic to serialization mechanism.
The perfect tool for such thing is
Data Contract. Please see:
http://msdn.microsoft.com/en-us/library/ms733127.aspx[
^].
Please also see my past answers where I advocate this approach. You don't have to change anything in your data, you only add some .NET
attributes. Please see:
How can I utilize XML File streamwriter and reader in my form application?[
^],
Creating property files...[
^],
deseralize a json string array[
^].
[EDIT]
See also:
http://en.wikipedia.org/wiki/Finite-state_machine[
^],
http://en.wikipedia.org/wiki/State_diagram[
^].
—SA
Submit an article or tip