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

Sub Form Cleanup

P: n/a
Using C# 3.5

I have a form that calls many other sub-forms. Typically there will be
five forms open at the same time.

If the main form is closed all the sub forms are also closed.

Is there a standard way to gain control within the sub-forms to do
individual clean-up prior to their removal?

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.
Jun 27 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Got it.

I was trying to capture it in the sub-forms and it must be done in the main
form.

(My only excuse ... sleep depravation.)

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.
Jun 27 '08 #2

P: n/a
On Tue, 13 May 2008 08:56:52 -0700, Thom Little <th**@tlanet.netwrote:
Using C# 3.5

I have a form that calls many other sub-forms. Typically there will be
five forms open at the same time.

If the main form is closed all the sub forms are also closed.

Is there a standard way to gain control within the sub-forms to do
individual clean-up prior to their removal?
You can override OnFormClosing() or OnFormClosed() in each sub-form to
detect when they are closed and do your necessary processing there.

I'm assuming that it's okay for all of the sub-forms to be closed when the
main form is closed. If that's not desirable behavior, you can change
that by not passing a specific form instance to Application.Run() in your
Program.cs file (just create and show the form and then call
Application.Run() without a parameter).

Pete
Jun 27 '08 #3

P: n/a
That is a simply great idea that I will keep in mind.

Unfortunately in this particular case the same sub-form generates four
variations based on a simple string that is passed to it.

For that reason I need to retain control on the main form. (4 shows and 4
closes)

Thanks for the help.

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.
Jun 27 '08 #4

P: n/a
On Tue, 13 May 2008 15:29:28 -0700, Thom Little <th**@tlanet.netwrote:
That is a simply great idea that I will keep in mind.

Unfortunately in this particular case the same sub-form generates four
variations based on a simple string that is passed to it.

For that reason I need to retain control on the main form. (4 shows and 4
closes)
I don't follow your logic. Just because you have four different instances
of the same class based on four different inputs, that doesn't mean you
can't handle "close" processing within that class. And IMHO, if the
processing is specific to each instance, then the processing belongs in
the sub-form class. Putting sub-form logic into the main form is contrary
to basic OOP design.

Pete
Jun 27 '08 #5

P: n/a
I was being imprecise (and perhaps dim).

There is one main form and one sub-form. There are four possible
permutations of how the sub-form is rendered. There can be one copy of each
sub-from. So lets call them A, B, C, and D.

Everything about how each is rendered is contained in the sub-form. The
definition of the six sub-forms in this example I think has to be in the
main form. There will a maximum of four calls to load the appropriate
versions and a maximum of four calls to close them all located in the main
form.

I capture the position where each sub-form is loaded when the main form is
shutdown and save them in the Registry. On reload, I restore the sub-forms
to where they were.

The nicest thing would be to have the sub-form pump out 0 to 4 updates to
the Registry when the main form is closed. I currently do that by
maintaining the instance in the main form and issue the appropriate sub-form
close calls on shutdown.

Am I missing something?

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.
Jun 27 '08 #6

P: n/a
On Wed, 14 May 2008 12:11:07 -0700, Thom Little <th**@tlanet.netwrote:
I was being imprecise (and perhaps dim).
Well, let's see if we can get the terminology correct.
There is one main form and one sub-form.
Do you mean "one main form class" and "one sub-form class"?
There are four possible
permutations of how the sub-form is rendered.
The word "rendered" usually implies a single visual update to the screen.
Are you saying that the "one sub-form class" will display itself in one of
four different ways depending on how it's initialized?
There can be one copy of each sub-from.
When you write "copy" do you really mean "instance"? When you write
"sub-form", do you mean (as above) "sub-form class"? If there is only
"one sub-form class", then what does it mean for there to be one copy "of
each sub-form class"?
So lets call them A, B, C, and D.

Everything about how each is rendered is contained in the sub-form.
If by "sub-form" you really mean "sub-form class", why does a single class
contain logic for displaying four different presentations? Wouldn't it be
more logical to have a different class for each presentation?
The
definition of the six sub-forms in this example I think has to be in the
main form.
What "definition"? And how do you get "six sub-forms"? Above, you only
have named four ("A, B, C, and D").
There will a maximum of four calls to load the appropriate
versions and a maximum of four calls to close them all located in the
main
form.
I understand that if there are to be four different instances of a form
class, you will need to make four calls to instantiate them. But as each
instance can itself monitor when it's closed, I don't see why the main
form need concern itself with that.
I capture the position where each sub-form is loaded when the main form
is
shutdown and save them in the Registry. On reload, I restore the
sub-forms
to where they were.
For saving location of each sub-form instance, it seems to me that _all_
of that logic can be places in the sub-form class. There should be no
need for the main form to concern itself with any of that, except perhaps
to provide to the sub-form class a storage container for storing the
location (in the event, for example, that you might have more than one
"main form" instance and you want each instance to be able to manage its
own sub-form instances separately).
The nicest thing would be to have the sub-form pump out 0 to 4 updates to
the Registry when the main form is closed.
In a .NET application, it is generally considered more appropriate to use
the configuration file API to store user state, settings, etc. The
registry isn't quite deprecated, but it might as well be.

In any case, I agree that "the nicest thing" would be to have the sub-form
class deal with saving the data. That's what I'm trying to say.
I currently do that by
maintaining the instance in the main form and issue the appropriate
sub-form
close calls on shutdown.
By default, closing your main form (that is, the form that is passed to
the Application.Run() method) will shut down the application, closing any
other forms in the process. You should not need to maintain any
references to the sub-forms (for this purpose, at any rate), as the forms
should be closed anyway. And of course, when the sub-forms are closed
implicitly by the closure of the main form, you can handle that in the
sub-form by overriding OnFormClosed().
Am I missing something?
You tell me. :)

It's very difficult to really understand what you're doing without an
appropriate concise-but-complete code sample that demonstrates exactly
what you're trying to do. Of particular amiguity is why you have a single
sub-form class that nevertheless is apparently used in four different
ways. But assuming that what you're doing is normal "user state
persistence", the basic question of whether the logic should go in the
main form or the sub-form class seems to be clearly on the "in the
sub-form class" side. I've seen nothing in this thread so far to suggest
that the logic belongs in the main class, never mind needs to be there.

Pete
Jun 27 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.