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
