how to save a component state?

  • Thread starter Thread starter Peter Verburgh
  • Start date Start date
P

Peter Verburgh

Hello,

Is there an easy way in C# to save a component (control) state (example.
save all the property values from a button control) to a file (xml) ?

Kind regards;

Peter.
 
Serializer and Deserializer, these are used for persistant storage ie.,
anything public in the type and subtypes (if not set to ignore in the
attributes) are written to XML.
 
So you just create a new object and pick off what you want to persist then
serialize that momento object.

Why they just dont say that at the start of the pattern examples is beyond
me, they just like to make it look fancy.

If you have control of the object you can always mark some properties as not
to be serialized.
 
Why they just dont say that at the start of the pattern examples is beyond
me, they just like to make it look fancy.
Click to expand...

;-)

The memento pattern is great for classes that hold references to parents or
other items in a linked list or stuff that's not at-all serializable. Many's
the time I've tried to serialize something and discovered that it holds a
reference to some sealed class somewhere. It enforces the rule of knowing
exactly what it is you're serializing and why, moreover it prevents you from
having to do stupid stuff like walk a tree of objects removing all the
things that cannot be serialized, doing the save and then walking the tree
putting all the stuff that was removed back again.

--
Bob Powell [MVP]
C#, System.Drawing

The October edition of Well Formed is now available.
Find out how to use DirectX in a Windows Forms control
http://www.bobpowell.net/currentissue.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm

Read my Blog at http://bobpowelldotnet.blogspot.com
 
Hi,

A slightly tongue-in-cheek look at Design patterns.

Design Pattersn are the result of some people noticing that certain -
guess what ;-) - patterns keep appearing in their code. They decided to
classify and catalogue - and thus Design Patterns became formalised and a
new discipline was born.

<Every single programmer> uses patterns - coding habits/techniques. Read
enough about Design Patterns and you'll find that a name has been given to
something you've already been doing, perhaps for years. (How many unrealised
Singleton Patterns must there be out there).

Often, giving a name to a pattern (and hence making it a <Design Pattern>)
will enable thinking to become clarified. It certainly enhances communication
between those who are 'in the know' - as does all jargon - though the downside
is that, of course, outsiders get excluded.

Another advantage is that a pattern, once formally designated, is open to
scrutiny, experimentation, enhancement, etc and there is somewhere to 'hang
the results' so that other people can benefit.

Many patterns are obvious once you have seen the code behind the name -
"yeah, ok, so they have a name for it". Others are a revelation "Hey! I can
use this!!". Others are in between - giving a new angle on something, a hint
or tip, an improvement. "Hmm, that looks a bit better than mine".

Some Design Patterns have not been catalogued, but are nevertheless widely
implemented. These tend to have a wide number of variations making
classification difficult, but would come under such headings as Plate of
Spaghetti, Can of Worms, Monolithic Block, Repetitious Garbage and the like.

In these days of OOP there are large numbers of classes following the
Grumpy Tiger Pattern - nobody dares look at it, let alone go near it!

Regards,
Fergus
 
Which beget antipatterns :).

Regards,
Jeff
Some Design Patterns have not been catalogued, but are nevertheless
Click to expand...
widely implemented. These tend to have a wide number of variations
making classification difficult, but would come under such headings as
Plate of Spaghetti, Can of Worms, Monolithic Block, Repetitious Garbage
and the like.<
 
Back
Top