Creating a preference window

  • Thread starter Thread starter melon
  • Start date Start date
M

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?
 
[...]
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?
Click to expand...

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
 
melon said:
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?
Click to expand...

Pass custom class as a parameter in your PreferenceForm constructor.

PS
 
Pass custom class as a parameter in your PreferenceForm constructor.
Click to expand...

It's a private class. It can't be passed to the PreferenceForm
constructor, because the PreferenceForm class doesn't have access to it.
 
melon said:
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?
Click to expand...

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
 
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?
Click to expand...

The PreferenceForm shouldn't modify the CustomClass.
Click to expand...

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
 
Peter Duniho said:
It's a private class. It can't be passed to the PreferenceForm
constructor, because the PreferenceForm class doesn't have access to it.
Click to expand...

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)
{
}
}
 
You are saying that this will not work?
Click to expand...

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
 
Peter Duniho said:
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.
Click to expand...

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

PS
 
Peter Duniho said:
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)
Click to expand...

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
 
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.
Click to expand...

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

preferred way to access mainform 1
Follow up 6
NEWBIE Q - accessing a form control from outside of the form class 1
Composite UI Application Block issues 3
Forms Flow 7
Reusing closed Winforms 11
Weird problem of nested ShowDialog() behavior 10
DataBinding multiple properties to a combobox 7

Back
Top