Form Serialization?

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
Mon Jul 14 16:01:36 CDT 2008

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" <jp2msft@discussions.microsoft.com> wrote in message
news:DDBCFDCE-E275-4693-B211-87D91DF98F93@microsoft.com...
> 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?

jp2msft
Mon Jul 14 16:28:04 CDT 2008

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" wrote:

> 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" <jp2msft@discussions.microsoft.com> wrote in message
> news:DDBCFDCE-E275-4693-B211-87D91DF98F93@microsoft.com...
> > 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
Mon Jul 14 16:56:48 CDT 2008

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" <jp2msft@discussions.microsoft.com> wrote in message
news:89AD9A1B-7F84-49BA-8A7C-0ADF5037C252@microsoft.com...
> 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" wrote:
>
>> 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" <jp2msft@discussions.microsoft.com> wrote in message
>> news:DDBCFDCE-E275-4693-B211-87D91DF98F93@microsoft.com...
>> > 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?
>>
>>
>>

jp2msft
Tue Jul 15 08:16:05 CDT 2008

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

"Alex Clark" wrote:

> 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" <jp2msft@discussions.microsoft.com> wrote in message
> news:89AD9A1B-7F84-49BA-8A7C-0ADF5037C252@microsoft.com...
> > 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" wrote:
> >
> >> 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" <jp2msft@discussions.microsoft.com> wrote in message
> >> news:DDBCFDCE-E275-4693-B211-87D91DF98F93@microsoft.com...
> >> > 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?
> >>
> >>
> >>
>
>
>

Duncan
Tue Jul 15 16:05:02 CDT 2008

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" <jp2msft@discussions.microsoft.com> wrote in message
news:F6539C5C-1903-4DFD-9FB4-8C677BDDA7A4@microsoft.com...
> 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
>
> "Alex Clark" wrote:
>
>> 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" <jp2msft@discussions.microsoft.com> wrote in message
>> news:89AD9A1B-7F84-49BA-8A7C-0ADF5037C252@microsoft.com...
>> > 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" wrote:
>> >
>> >> 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" <jp2msft@discussions.microsoft.com> wrote in message
>> >> news:DDBCFDCE-E275-4693-B211-87D91DF98F93@microsoft.com...
>> >> > 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?
>> >>
>> >>
>> >>
>>
>>
>>

jp2msft
Tue Jul 15 16:37:08 CDT 2008

Hi Mr. Jones,

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

"Duncan Jones" wrote:

> 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" <jp2msft@discussions.microsoft.com> wrote in message
> news:F6539C5C-1903-4DFD-9FB4-8C677BDDA7A4@microsoft.com...
> > 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
> >
> > "Alex Clark" wrote:
> >
> >> 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" <jp2msft@discussions.microsoft.com> wrote in message
> >> news:89AD9A1B-7F84-49BA-8A7C-0ADF5037C252@microsoft.com...
> >> > 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" wrote:
> >> >
> >> >> 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" <jp2msft@discussions.microsoft.com> wrote in message
> >> >> news:DDBCFDCE-E275-4693-B211-87D91DF98F93@microsoft.com...
> >> >> > 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?
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>