Form Serialization?

[jp2msft]

Can a Form be set to Serializable?

My App keeps crashing ever time I attempt to serialize the form.

I was under the impression that Serialization could be used to easily save
all of my data. If the form can not be serialized, how to I save the
information on it?

 

[Alex Clark]

Serialization only works on classes that are decorated with the
Serializable() attribute. System.Windows.Forms.Form is not.

You cannot serialize a form (or a control, or other disposable resource) for
various reasons. Imagine if you serialized it to a file, then deserialized
it later into a form - what happens to the handles? What if an existing
control has an identical handle to one of the controls on the form you're
trying to deserialize?

The solution is to create a class that holds the data (and just the data)
that you want to save, and decorate that class with the serializable
attribute. You can then use that for saving/loading data on a form.

Kind Regards,
Alex

 

[jp2msft]

Thanks Mr. Clark,

I guess that makes sense. It sure would have been nice if the entire state
of the form could magically have been saved (date ranges, form position &
size, query strings, and maybe query results).

Yuck. Now I have to grunt it out.

 

[Alex Clark]

Hi,

There *might* be a more re-usable solution to your problem in the form of
Reflection.

You could use Reflection to identify all Read/Write properties on the form
in question (which would exclude Handle, along with a few others) and then
add them to a Dictionary object which you can then serialize. Simply
reverse the process for deserialization.

Don't forget though that things like the titlebar text will be serialized as
well - if you're using that for any kind of status indication, it may be a
gotcha. Also, if further down the line you opt to change the background
colour of your form, any saved data from the past will cause it to revert to
what it was before!

The above solution would only work for the form itself. If you wanted to do
it for everything on the form, you're looking at recursively drilling down
through each control contained within the form, and their controls, and so
on. Then you have to come up with a structured naming convention (like
"MyForm/MainPanel/OptionFrame/Panel3/ControlName.Text").

It really does start to get a bit ugly after a while, but depending on the
situation it could work out better for you than manually going through all
the properties you want. The danger is when you realise you only want to
store about a quarter of the form's read/write properties in the first
place, and that's when it might be a good idea to just bite the bullet and
do it yourself.

Cheers,
Alex Clark

 

[jp2msft]

Good food for thought.

Thanks for your help! I've got some stuff saving, and at least now I know
how to save the rest.

Regards,
Joe

 

[Duncan Jones]

Other possibilities:
(1) Use databinding to bind you form controls to a data set
or
(2) Write a class that is based off the
System.ComponentModel.IExtenderProvider class to provide serialisation
options to all the controls on a form
or
(3) Write an extension method for the Control class

 

[jp2msft]

Hi Mr. Jones,

I'd be interested in hearing more about these ideas, especially #2 and #3.
Are there tutorials on these techniques someplace?