way to save all form properties in a file

Question

1.00/5 (1 vote)

See more:

how would I save all form information in a valid way like window state, width, top, height, left and font size, font type and color of the closing form in a file which directory I can choose freely and which name I can choose freely. Is there any .NET function for it. I don't mean Application Settings since this did not fullfill my requirements of controlling where to save the file and there are not those data types which I would need. I also could not find INI access functions in the File namespace. Any other ideas?

I would like to choose the directory and filename where this data is saved to. With Application Settings I see no way of doing this. I even don't know where the data is stored and therefore can't backup it. So I search for another common and professional way of doing this easier.

Update:
I definitely wish to specify the location of the data and definitely wish to save it in a binary or INI storage format with .NET inbuilt functions within NET 2.0.
I definitely wish only to save the forms data at first.

Posted 3-Mar-15 2:00am

Grumpyman

Updated 13-Mar-15 5:09am

v3

Add a Solution

Comments

BillWoodruff 3-Mar-15 11:37am

And, what about the Controls on your Form ? What about Controls in Controls, like Buttons in a Panel ? You wish to save the state/attributes of those also ? See my comments on Adrian's answer below for more details.

Richard MacCutchan 28-Mar-15 13:36pm

If you cannot respond without being abusive you are likely to find yourself removed from the site.

3 solutions

Solution 1

See User Preference using Application Settings[^].

Posted 3-Mar-15 2:26am

Richard MacCutchan

Comments

CHill60 3-Mar-15 10:16am

You could adapt the principle but write the data to an XML file of your choice - C# Application with XML File[^] for example

Richard MacCutchan 3-Mar-15 10:56am

Another way of doing this is likely not easier, but more difficult. Using the Application Settings is far and away the most sensible option. But hey, it's your time you are wasting.

Sergey Alexandrovich Kryukov 3-Mar-15 11:03am

I am sure it is not, also by far... :-)
—SA

Sergey Alexandrovich Kryukov 3-Mar-15 11:02am

This is the Solution 3, please see. It does what you want, plus it is much easier to use, way more flexible and robust. I never use Application Settings, consider it obsolete.
—SA

Richard MacCutchan 3-Mar-15 11:09am

Why would I consider it obsolete?

Sergey Alexandrovich Kryukov 3-Mar-15 11:19am

I do, you may not. Why? Because there are much more robust and flexible ways, also easier to use. Or, if you will, it is not obsolete, because it can be practical for some simplest cases.
—SA

Solution 2

I stand corrected. Instead of attributes I actually was thinking of getType().getProperties(). It's been some time since I used them.

I suggest creating a helper class that will iterate through a instance properties using reflection.

Here are some reference links :
This will get you an array of PropertyInfo objects.
https://msdn.microsoft.com/en-us/library/aky14axb(v=vs.110).aspx[^]

Using the PropertyInfo instance you can call GetValue to retrieve each properties value.
https://msdn.microsoft.com/en-us/library/system.reflection.propertyinfo(v=vs.110).aspx[^]

This helper class can be customized to have a output file name and location where to save the found attributes and using a StreamWriter you can save these attributes.

Posted 3-Mar-15 3:51am

Adrian Vaideanu

Updated 3-Mar-15 23:12pm

v2

Comments

Sergey Alexandrovich Kryukov 3-Mar-15 11:01am

Good idea, my 5.
I also added better serialization solution, please see Solution 3.
—SA

BillWoodruff 4-Mar-15 0:59am

I think this is not a good idea. Attributes are defined at design-time; how would you change the value of an Attribute at run-time to reflect current state ?

Yes, you can modify INSTANCES of Attributes of Classes at run-time, but there are complications, possible esoteric limiting options. See the discussion here for some sobering information on trying to do this:

http://stackoverflow.com/questions/51269/change-attributes-parameter-at-runtime

Attributes are meant to be "static" meta-information that decorate object declarations: you "consume" them at run-time for whatever purpose, but, imho, unless you are a very advanced .NET programmer, and absolutely have no other alternative, I think you should modifying Attributes.

Most likely the OP here will want to save dynamic state at run-time: the current size, position, etc., of Controls, for Example.

Use of Attributes is appropriate for many other uses, however, including in AOP, etc.

Adrian Vaideanu 4-Mar-15 5:13am

Thanks for notice. I updated my answer.

BillWoodruff 4-Mar-15 20:03pm

Thank you, Adrian; your original answer caused me to re-evaluate my understanding of what can, and can't be done, with Attributes, and I learned something new !

My vote raised to #4.

Adrian Vaideanu 13-Mar-15 11:15am

I dont't know of an existing method to save these properties which is already implemented in the .NET framework.

But what I do know is that .NET offers the necessary support for file creating/reading and since you can get the properties values as I described it should be easy for you to implement such a functionality. The same can be said about reading and restoring these properties.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-03-03T05:00:00

Solution 3

Solution 2 gives you a good idea. You can use it or use some fixed data structures; I want to add the solution in part of saving and restoring some arbitrary data:

I think Application Settings is the obsolete feature, it is not flexible enough to me, so I never use it and never advise. There is a newer, much more robust technique, which is one of the forms of serialization:
https://msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx[^].

This approach is, by far, the easiest to use and very robust: you don't have to think about the file operations at all (XML, in this case). You just make the contract from any data structures consisting of one or several data types. The approach is non-intrusive, there are no essential requirements or limitations to your data classes; you just add some attributes which don't modify any behavior except the persistence. The serializer saves any arbitrary object graph (does not even have to be a tree) to any stream, to later restore it in memory the way it was before.

Please see my past answer advocating this approach:
How can I utilize XML File streamwriter and reader in my form application?[^],
Creating property files...[^].

—SA

Posted 3-Mar-15 5:00am

Sergey Alexandrovich Kryukov

Comments

BillWoodruff 4-Mar-15 0:56am

+5 imho, using DataContract is the best way to go. In this case, it would be interesting to know to what "depth" the OP wishes to save run-time state; i.e., if the end-user can move/resize Controls, wants to save the state of a TreeView's Nodes modified at run-time, etc.

Sergey Alexandrovich Kryukov 13-Mar-15 10:46am

What difference it can possibly make? How can serialization depend on application type?
I never ever even meant "HTML application" (what would you mean by that? :-). Your "not usable" is not based on anything. Who told you this absurd?
Here is what I recommend: accept my answer formally and actually use this solution.
—SA

Sergey Alexandrovich Kryukov 13-Mar-15 11:27am

??? You are very welcome... Who suggested to save your data in HTML?!
Of course, it's all up to you. Just better be careful, because you level of understanding things leads you to trouble. You manage to mess up everything.
—SA

Sergey Alexandrovich Kryukov 13-Mar-15 11:47am

There is no problem in expressing opinions here, but you are just messing up communication; I tried to explain how. You did not understand the suggestions at all.

Now, a bit of information: the Data Contract approach is exactly the way to persist data in XML without ever touching XML. You can have any data object graph and store it, and, some time later, restore it back in memory as it was before. This approach in non-intrusive, because you don't have to modify your code (data model), you just add some attributes which cannot affect your functionality. Other methods would require implementing some special interfaces, or derive from some existing types, something like that. Data Contract approach does not require anything.

But this is not my goal to do the propaganda. It's all up to you. But if you don't want to see the opportunities created for you quite professionally, who would be the loser? This is the case when you unlikely are able to invent the better wheel...

—SA

Sergey Alexandrovich Kryukov 13-Mar-15 14:46pm

The whole approach if looking for the solution matching your criteria is very wrong. "Fits my needs" would be fine, but even that could be questionable, because you might not correctly recognize you needs. And "fits my knowledge level" is a straight way to a dead end. If you want to keep things at your knowledge level, you will come nowhere.

(How good is your knowledge level? I don't want to frustrate you or judge in any way, but let me tell you that using Data Contracts is probably the very simplest among all possible activities related to storing any kinds of properties. When you think (hopefully, mistakenly) that this is above your head, wouldn't it be logical to conclude that the whole idea to store and restore properties itself is also above your head? This is the way to go nowhere: you give up in advance. On this example, can you see how you can create a dead-end way?)

Just something for you to think about...

—SA