Creating a preference window

[melon]

Let's say, I have a form class...

public class MainForm : Form {
private CustomClass cc;

public MainForm() {
DoSomething()
InitializeComponent();
}
/// Do something more
public void ShowPreference() {
PreferenceForm pf = new PreferenceForm();
pf.sometextbox.text = cc.something;
/// etc
pf.ShwoDialog();
}
}

public class PreferenceForm: Form {
/// another form
}

Basically, when the user try to close the Preference form, I want it
to be able to modify my Custom class in my main form directly.... how
could I do that?

[Peter Duniho]

On Thu, 10 May 2007 13:36:57 -0700, melon <el*****@gmail.comwrote:

[...]
Basically, when the user try to close the Preference form, I want it
to be able to modify my Custom class in my main form directly.... how
could I do that?

As long as that class is private to your MainForm class, you can't have
the PreferenceForm modify it directly.

One way is to make the class public and allow the PreferenceForm to keep a
reference to an instance of that class. The reference would be given to
the PreferenceForm by your MainForm class before showing the dialog (by
passing it in the constructor for PreferenceForm, by setting a property,
by calling a method, whatever), and then the PreferenceForm could access
it that way. A slight variation on this theme is to just make a public
interface (probably declared by the settings dialog class, but you could
put it anywhere that is accessible to both) that your private class can
expose and pass to the settings dialog.

Another way is to expose dialog input as properties in the dialog's class
and then have the client of that class use those to apply them when I use
the dialog. This requires a little more typing, but it means that the
settings dialog isn't tied to the client's class. In many cases, the
settings in the dialog are so specific to the client that having it be
aware of the client isn't really a problem, but sometimes you'll have a
dialog that is more general-purpose. Being in the habit of keeping the
two seperated means that you can always reuse the dialog when appropriate,
without having to do additional design work.

Any of these methods seem acceptable to me. Which one works best for you
depends mostly just on what seems to fit in best with the rest of your
architectural style.

Pete

[PS]

"melon" <el*****@gmail.comwrote in message
news:11**********************@h2g2000hsg.googlegro ups.com...

Let's say, I have a form class...

public class MainForm : Form {
private CustomClass cc;

public MainForm() {
DoSomething()
InitializeComponent();
}
/// Do something more
public void ShowPreference() {
PreferenceForm pf = new PreferenceForm();
pf.sometextbox.text = cc.something;
/// etc
pf.ShwoDialog();
}
}

public class PreferenceForm: Form {
/// another form
}

Basically, when the user try to close the Preference form, I want it
to be able to modify my Custom class in my main form directly.... how
could I do that?

Pass custom class as a parameter in your PreferenceForm constructor.

PS

[Peter Duniho]

On Thu, 10 May 2007 14:31:58 -0700, PS <ec***********@hotmail.comwrote:

Pass custom class as a parameter in your PreferenceForm constructor.

It's a private class. It can't be passed to the PreferenceForm
constructor, because the PreferenceForm class doesn't have access to it.

[Christof Nordiek]

"melon" <el*****@gmail.comschrieb im Newsbeitrag
news:11**********************@h2g2000hsg.googlegro ups.com...

Let's say, I have a form class...

public class MainForm : Form {
private CustomClass cc;

public MainForm() {
DoSomething()
InitializeComponent();
}
/// Do something more
public void ShowPreference() {
PreferenceForm pf = new PreferenceForm();
pf.sometextbox.text = cc.something;
/// etc
pf.ShwoDialog();
}
}

public class PreferenceForm: Form {
/// another form
}

Basically, when the user try to close the Preference form, I want it
to be able to modify my Custom class in my main form directly.... how
could I do that?

The PreferenceForm shouldn't modify the CustomClass.
The PreferenceForm should have a property, wich after closing returns the
result. Then the MainForm can modify its components itself. So the
PreferenceForm simply fetches input from the user, and the Mainform decides
what to do with that input.

Christof

[Peter Duniho]

On Fri, 11 May 2007 07:22:40 -0700, Christof Nordiek <[e-mail]:

>public class MainForm : Form {
private CustomClass cc;

[...]

Basically, when the user try to close the Preference form, I want it
to be able to modify my Custom class in my main form directly.... how
could I do that?

The PreferenceForm shouldn't modify the CustomClass.

Note that this is strictly a matter of personal preference. There is no
fundamental reason you cannot implement it that way if you want (though in
this case, the access modifier for CustomClass would have to be changed to
allow it)

Pete

[PS]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Thu, 10 May 2007 14:31:58 -0700, PS <ec***********@hotmail.comwrote:

>Pass custom class as a parameter in your PreferenceForm constructor.

It's a private class. It can't be passed to the PreferenceForm
constructor, because the PreferenceForm class doesn't have access to it.

You are saying that this will not work?

public class MainForm : Form {
private CustomClass cc;

public MainForm() {
DoSomething()
InitializeComponent();
}
/// Do something more
public void ShowPreference() {
PreferenceForm pf = new PreferenceForm(cc);
pf.sometextbox.text = cc.something;
/// etc
pf.ShwoDialog();
}
}

public class PreferenceForm: Form {
/// another form

public PreferenceForm(CustomClass cc)
{
}
}

[Peter Duniho]

On Sat, 12 May 2007 05:46:11 -0700, PS <ec***********@hotmail.comwrote:

>It's a private class. It can't be passed to the PreferenceForm
constructor, because the PreferenceForm class doesn't have access to it.

You are saying that this will not work?

Yes, that's what I'm saying. You are trying to access the CustomClass
type from your PreferenceForm class, but it's private to the MainForm
class and so not visible to the PreferenceForm class.

Pete

[PS]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Sat, 12 May 2007 05:46:11 -0700, PS <ec***********@hotmail.comwrote:

>>It's a private class. It can't be passed to the PreferenceForm
constructor, because the PreferenceForm class doesn't have access to it.

You are saying that this will not work?

Yes, that's what I'm saying. You are trying to access the CustomClass
type from your PreferenceForm class, but it's private to the MainForm
class and so not visible to the PreferenceForm class.

No it isn't. Reread the code. cc is an INSTANCE not the class definition.

PS

[Peter Duniho]

On Sat, 12 May 2007 11:54:46 -0700, PS <ec***********@hotmail.comwrote:

No it isn't. Reread the code. cc is an INSTANCE not the class definition.

Ah. Okay, you're right. I misread the code. Sorry about that.

[Christof Nordiek]

"Peter Duniho" <Np*********@nnowslpianmk.comschrieb im Newsbeitrag
news:op***************@petes-computer.local...

On Fri, 11 May 2007 07:22:40 -0700, Christof Nordiek <[e-mail]:

<snip>

>The PreferenceForm shouldn't modify the CustomClass.

Note that this is strictly a matter of personal preference. There is no
fundamental reason you cannot implement it that way if you want (though in
this case, the access modifier for CustomClass would have to be changed to
allow it)

Surely you can implement it in that way. But there are fundamental reason,
why you shouldn't.
First: Making the field public, allows other classes not only to access the
control, but even to assign another control to that variable.
Second and more important: The PreferenceForm has to know, where to store
the results in its calling form. This strongly reduces the reusability of
that form and the maintainability of the code.

PreferenceForm should only be responsible for getting some input of the user
and the calling form should represent that changes in its controls.

Christof

[Peter Duniho]

On Mon, 14 May 2007 00:24:33 -0700, Christof Nordiek <[e-mail]:

Surely you can implement it in that way. But there are fundamental
reason, why you shouldn't.
First: Making the field public, allows other classes not only to access
the control, but even to assign another control to that variable.
Second and more important: The PreferenceForm has to know, where to store
the results in its calling form. This strongly reduces the reusability of
that form and the maintainability of the code.

Note that when I wrote that statement, I was under the incorrect
impression that the "private CustomClass" was a class declaration rather
than a field declaration. I have no good explanation for why I misread
the code in such an obviously wrong way. But I did. :)

I certainly agree that a field should not be public, as well as with most
of the rest of what you wrote. I agree that the PreferenceForm should not
be strongly tied to the calling form's class.

That said, to some extent a "preferences" dialog form is always going to
be custom to at least some class of forms, if not to a specific form. So
while I agree that fields shouldn't be made public, I don't think it's
terrible for the PreferenceForm to have *some* knowledge of the calling
form (such as using a specific shared class to communicate the data). As
an example, one idea I've been kicking around is having the PreferenceForm
public an interface that the calling form is required to implement, and
which the calling form passes to the PreferenceForm.

I don't have any great reasons for thinking this is better than having the
data flow the other direction (it has the "preferences" dialog manage the
data flow, while the alternative has the calling form manage the data
flow), but I also don't have any great reasons for thinking it's worse in
any way. One way or the other, the calling form has to implement some
sort of "glue" to connect to the "preferences" dialog form, so it seems to
me that whether it implements an interface or accesses properties on the
dialog form or whatever, it's all the same in the end. :)

Pete