By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,436 Members | 2,979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,436 IT Pros & Developers. It's quick & easy.

When to save values from a UserControl

P: n/a
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
Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
maybe Unload?

Nov 17 '05 #2

P: n/a
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.
"re*****@gmail.com" wrote:
maybe Unload?

Nov 17 '05 #3

P: n/a
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.

"Javaman59" wrote:
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.
"re*****@gmail.com" wrote:
maybe Unload?

Nov 17 '05 #4

P: n/a
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

"Javaman59" <Ja*******@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...
| 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
Nov 17 '05 #5

P: n/a
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.

Nov 17 '05 #6

P: n/a
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

"Bruce Wood" wrote:
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.

Nov 17 '05 #7

P: n/a
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

Hope this helps
Jay

"Javaman59" <Ja*******@discussions.microsoft.com> wrote in message
news:B0**********************************@microsof t.com...
| 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

Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.