When to save values from a UserControl

[Guest]

This is about finding the right point at which to save user entered data in
the registry, so that when the application is restarted, the saved values
will be restored. I want this behaviour to be automatic - ie, it happens
every time, without the user pressing "OK", or "Save", whaterver..

With a Form, it is easy. Add an event handler for the Closed event, for
saving, and the Load event, for restoring.

A UserControl is more difficult. It has a Load event, which I'll use for
restoring the values, but no Close event.

When should I save values from a UserControl?

TIA,

Javaman

 

[realfun]

maybe Unload?

 

[Guest]

Thanks, that would be just the one, if I was making a
System.Web.UI.UserControl.

It's not clear from my question that I'm in System.Windows.Forms.UserControl
land.

 

[Guest]

I don't think you would want the control to be responsible for its own data
persistence. I would just code public get/set methods on the UserControl and
have the base form handle persistence and initialization of the control in
its load and close events.

 

[Jay B. Harlow [MVP - Outlook]]

Javaman59,
Like Joe I would question the control being responsible for saving its own
data.

However have you tried using ContainerControl.ParentForm property to add a
handler to Form.Close.

Then when the Form closes your control can do its cleanup?

Alternatively you could override Dispose(bool) method & save the settings
there. As long as the Form is closed & disposed of properly, then your
settings will be saved properly...

Hope this helps
Jay

| This is about finding the right point at which to save user entered data
in
| the registry, so that when the application is restarted, the saved values
| will be restored. I want this behaviour to be automatic - ie, it happens
| every time, without the user pressing "OK", or "Save", whaterver..
|
| With a Form, it is easy. Add an event handler for the Closed event, for
| saving, and the Load event, for restoring.
|
| A UserControl is more difficult. It has a Load event, which I'll use for
| restoring the values, but no Close event.
|
| When should I save values from a UserControl?
|
| TIA,
|
| Javaman

 

[Bruce Wood]

I just finished writing a nifty subsystem for doing exactly this.

I have a central, static class for handling persistence to the
Registry. Let's call it Persist. A form can call Persist asking Persist
to save its state under a given Registry key. Persist picks up the
current size / maximized state / etc of the form and saves it to the
Registry.

Here's the neat part: it then does a recursive walk down the Controls
collection tree (iterates the Controls collection, and then for each
control iterates its Controls, etc), persisting "interesting stuff" for
each control it encounters.

The only two problems are: what constitutes "interesting", and should
Persist recurse inside a control? Persist solves these problems by
holding a static hash table, keyed by Type, of objects that contain
serialization and deserialization delegates, and indications of whether
to continue recursing down the Controls tree. Each Type of Control has
an entry in the hash table. If a control type has no entry, then there
is nothing to persist, but Persist should recurse inside it, looking
for more controls.

Each new kind of UserControl I create has a static constructor that
tells Persist how it should be persisted in the Registry: it supplies
(static) serialization and deserialization delegates, and tells Persist
whether to recurse inside it.

Persist itself has a static constructor for adding instructions
regarding standard System.Windows.Forms controls.

The whole thing works very well: all you have to do is call Persist in
OnLoad and OnClose for your forms, and create a static initializer for
any new controls you create. Once you've done that, you can design /
redesign the form any way you like and Persist will automatically
adapt.

The only minor glitches are that every control on your form has to have
a Name (the Designer gives them names anyway), and that if you redesign
a form (change control names / move controls between panels or group
boxes, etc), Persist may not find the old Registry setting the next
time you start the app, so upgrades to the app can temporarily lose
persisted settings. However, I don't consider that a really big deal.

 

[Guest]

G'day Bruce

Thanks for the long and detailed reply. It's the weekend for me now, so I'm
not programming, but what you've got here looks like it might be the solution
I'm after.

- Stephen

 

[Guest]

Thanks Jay,

Like Joe I would question the control being responsible for saving its own
data.

Something to think about. (and thanks Joe)

However have you tried using ContainerControl.ParentForm property to add a
handler to Form.Close. Then when the Form closes your control can do its
cleanup?

Good suggestion. I think that would work.

Alternatively you could override Dispose(bool) method & save the settings
there. As long as the Form is closed & disposed of properly, then your
settings will be saved properly...

That's one thing I thought of, but decided against. I think that the Dispose
method should be kept strictly for clean-up, and not adding functionality to
the form.

Regards,

Stephen