How to access a form control for another form?
I have two Form
classes, one of which has a ListBox
. I need a setter for the SelectedIndex
property of the ListBox
, which I want to call from the second Form
.
At the moment I am doing the following:
Form 1
public int MyListBoxSelectedIndex
{
set { lsbMyList.SelectedIndex = value; }
}
Form 2
private ControlForm mainForm; // form 1
public AddNewObjForm()
{
InitializeComponent();
mainForm = new ControlForm();
}
public void SomeMethod()
{
mainForm.MyListBoxSelectedIndex = -1;
}
Is this the best way to do this?
c# winforms controls
add a comment |
I have two Form
classes, one of which has a ListBox
. I need a setter for the SelectedIndex
property of the ListBox
, which I want to call from the second Form
.
At the moment I am doing the following:
Form 1
public int MyListBoxSelectedIndex
{
set { lsbMyList.SelectedIndex = value; }
}
Form 2
private ControlForm mainForm; // form 1
public AddNewObjForm()
{
InitializeComponent();
mainForm = new ControlForm();
}
public void SomeMethod()
{
mainForm.MyListBoxSelectedIndex = -1;
}
Is this the best way to do this?
c# winforms controls
Interaction between forms — How to change a control of a form from another form?
– Reza Aghaei
Nov 4 '17 at 21:13
add a comment |
I have two Form
classes, one of which has a ListBox
. I need a setter for the SelectedIndex
property of the ListBox
, which I want to call from the second Form
.
At the moment I am doing the following:
Form 1
public int MyListBoxSelectedIndex
{
set { lsbMyList.SelectedIndex = value; }
}
Form 2
private ControlForm mainForm; // form 1
public AddNewObjForm()
{
InitializeComponent();
mainForm = new ControlForm();
}
public void SomeMethod()
{
mainForm.MyListBoxSelectedIndex = -1;
}
Is this the best way to do this?
c# winforms controls
I have two Form
classes, one of which has a ListBox
. I need a setter for the SelectedIndex
property of the ListBox
, which I want to call from the second Form
.
At the moment I am doing the following:
Form 1
public int MyListBoxSelectedIndex
{
set { lsbMyList.SelectedIndex = value; }
}
Form 2
private ControlForm mainForm; // form 1
public AddNewObjForm()
{
InitializeComponent();
mainForm = new ControlForm();
}
public void SomeMethod()
{
mainForm.MyListBoxSelectedIndex = -1;
}
Is this the best way to do this?
c# winforms controls
c# winforms controls
edited Dec 14 '12 at 23:53
wulfgarpro
asked Jan 27 '11 at 23:01
wulfgarprowulfgarpro
3,44485295
3,44485295
Interaction between forms — How to change a control of a form from another form?
– Reza Aghaei
Nov 4 '17 at 21:13
add a comment |
Interaction between forms — How to change a control of a form from another form?
– Reza Aghaei
Nov 4 '17 at 21:13
Interaction between forms — How to change a control of a form from another form?
– Reza Aghaei
Nov 4 '17 at 21:13
Interaction between forms — How to change a control of a form from another form?
– Reza Aghaei
Nov 4 '17 at 21:13
add a comment |
5 Answers
5
active
oldest
votes
I usually use the Singleton Design Pattern for something like this http://en.wikipedia.org/wiki/Singleton_pattern . I'll make the main form that the application is running under the singleton, and then create accessors to forms and controls I want to touch in other areas. The other forms can then either get a pointer to the control they want to modify, or the data in the main part of the application they wish to change.
Another approach is to setup events on the different forms for communicating, and use the main form as a hub of sorts to pass the event messages from one form to another within the application.
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
add a comment |
Making them Singleton is not a completely bad idea, but personally I would not prefer to do it that way. I'd rather pass the reference of one to another form. Here's an example.
Form1 triggers Form2 to open. Form2 has overloaded constructor which takes calling form as argument and provides its reference to Form2 members. This solves the communication problem. For example I've exposed Label Property as public in Form1 which is modified in Form2.
With this approach you can do communication in different ways.
Download Link for Sample Project
//Your Form1
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frm = new Form2(this);
frm.Show();
}
public string LabelText
{
get { return Lbl.Text; }
set { Lbl.Text = value; }
}
}
//Your Form2
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private Form1 mainForm = null;
public Form2(Form callingForm)
{
mainForm = callingForm as Form1;
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
}
private void button1_Click(object sender, EventArgs e)
{
this.mainForm.LabelText = txtMessage.Text;
}
}
alt text http://demo.ruchitsurati.net/files/frm1.png
alt text http://demo.ruchitsurati.net/files/frm2.png
1
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
7
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
2
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
4
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
2
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
|
show 1 more comment
Access the form's controls like this: formname.controls[Index]
.
You can cast as appropriate control type, Example:DataGridView dgv = (DataGridView) formname.Controls[Index];
add a comment |
There is one more way, in case you don't want to loop through "ALL" controls like Joe Dabones suggested.
Make a function in Form2 and call it from Form1.
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public void SetIndex(int value)
{
lsbMyList.SelectedIndex = value;
}
}
public partial class Form1 : Form
{
public Form2 frm;
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
frm=new Form2();
frm.Show();
}
private void button1_Click(object sender, EventArgs e)
{
frm.SetIndex(Int.Parse(textBox1.Text));
}
}
add a comment |
It's easy, first you can access the other form like this:
(let's say your other form is Form2
)
//in Form 1
Form2 F2 = new Form2();
foreach (Control c in F2.Controls)
if(c.Name == "TextBox1")
c.Text = "hello from Form1";
That's it, you just write in TextBox1
in Form2
from Form1
.
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
add a comment |
protected by Community♦ Nov 28 '12 at 19:42
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
I usually use the Singleton Design Pattern for something like this http://en.wikipedia.org/wiki/Singleton_pattern . I'll make the main form that the application is running under the singleton, and then create accessors to forms and controls I want to touch in other areas. The other forms can then either get a pointer to the control they want to modify, or the data in the main part of the application they wish to change.
Another approach is to setup events on the different forms for communicating, and use the main form as a hub of sorts to pass the event messages from one form to another within the application.
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
add a comment |
I usually use the Singleton Design Pattern for something like this http://en.wikipedia.org/wiki/Singleton_pattern . I'll make the main form that the application is running under the singleton, and then create accessors to forms and controls I want to touch in other areas. The other forms can then either get a pointer to the control they want to modify, or the data in the main part of the application they wish to change.
Another approach is to setup events on the different forms for communicating, and use the main form as a hub of sorts to pass the event messages from one form to another within the application.
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
add a comment |
I usually use the Singleton Design Pattern for something like this http://en.wikipedia.org/wiki/Singleton_pattern . I'll make the main form that the application is running under the singleton, and then create accessors to forms and controls I want to touch in other areas. The other forms can then either get a pointer to the control they want to modify, or the data in the main part of the application they wish to change.
Another approach is to setup events on the different forms for communicating, and use the main form as a hub of sorts to pass the event messages from one form to another within the application.
I usually use the Singleton Design Pattern for something like this http://en.wikipedia.org/wiki/Singleton_pattern . I'll make the main form that the application is running under the singleton, and then create accessors to forms and controls I want to touch in other areas. The other forms can then either get a pointer to the control they want to modify, or the data in the main part of the application they wish to change.
Another approach is to setup events on the different forms for communicating, and use the main form as a hub of sorts to pass the event messages from one form to another within the application.
answered Jan 27 '11 at 23:37
ColinCrenColinCren
558212
558212
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
add a comment |
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
Why wouldn't you just use events? This is what they are for, communication between objects without tight coupling.
– Ed S.
Jan 28 '11 at 0:33
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
@Ed Swangren - That's why I suggested them as well. It's totally an option, though it requires a whole lot more time to do each individual event as you want to add new hooks, while a singleton is pretty much a one time thing. My personal favorite thing to do is to abstract the UI out from the core behavior of the application. That core then is the singleton, and can have events attached to it. Then all UI is just a view of the data within the core. This makes doing undo/redo behaviors much much easier.
– ColinCren
Jan 28 '11 at 1:56
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
I don't see any requirement for undo-redo behavior, and I disagree with your statement that implies that seting up events is an onerous task. Singletons are often a crappy solution to any problem. I was going to list some supporting arguments, bit I found a pretty good list here: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
– Ed S.
Jan 28 '11 at 8:26
add a comment |
Making them Singleton is not a completely bad idea, but personally I would not prefer to do it that way. I'd rather pass the reference of one to another form. Here's an example.
Form1 triggers Form2 to open. Form2 has overloaded constructor which takes calling form as argument and provides its reference to Form2 members. This solves the communication problem. For example I've exposed Label Property as public in Form1 which is modified in Form2.
With this approach you can do communication in different ways.
Download Link for Sample Project
//Your Form1
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frm = new Form2(this);
frm.Show();
}
public string LabelText
{
get { return Lbl.Text; }
set { Lbl.Text = value; }
}
}
//Your Form2
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private Form1 mainForm = null;
public Form2(Form callingForm)
{
mainForm = callingForm as Form1;
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
}
private void button1_Click(object sender, EventArgs e)
{
this.mainForm.LabelText = txtMessage.Text;
}
}
alt text http://demo.ruchitsurati.net/files/frm1.png
alt text http://demo.ruchitsurati.net/files/frm2.png
1
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
7
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
2
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
4
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
2
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
|
show 1 more comment
Making them Singleton is not a completely bad idea, but personally I would not prefer to do it that way. I'd rather pass the reference of one to another form. Here's an example.
Form1 triggers Form2 to open. Form2 has overloaded constructor which takes calling form as argument and provides its reference to Form2 members. This solves the communication problem. For example I've exposed Label Property as public in Form1 which is modified in Form2.
With this approach you can do communication in different ways.
Download Link for Sample Project
//Your Form1
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frm = new Form2(this);
frm.Show();
}
public string LabelText
{
get { return Lbl.Text; }
set { Lbl.Text = value; }
}
}
//Your Form2
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private Form1 mainForm = null;
public Form2(Form callingForm)
{
mainForm = callingForm as Form1;
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
}
private void button1_Click(object sender, EventArgs e)
{
this.mainForm.LabelText = txtMessage.Text;
}
}
alt text http://demo.ruchitsurati.net/files/frm1.png
alt text http://demo.ruchitsurati.net/files/frm2.png
1
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
7
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
2
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
4
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
2
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
|
show 1 more comment
Making them Singleton is not a completely bad idea, but personally I would not prefer to do it that way. I'd rather pass the reference of one to another form. Here's an example.
Form1 triggers Form2 to open. Form2 has overloaded constructor which takes calling form as argument and provides its reference to Form2 members. This solves the communication problem. For example I've exposed Label Property as public in Form1 which is modified in Form2.
With this approach you can do communication in different ways.
Download Link for Sample Project
//Your Form1
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frm = new Form2(this);
frm.Show();
}
public string LabelText
{
get { return Lbl.Text; }
set { Lbl.Text = value; }
}
}
//Your Form2
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private Form1 mainForm = null;
public Form2(Form callingForm)
{
mainForm = callingForm as Form1;
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
}
private void button1_Click(object sender, EventArgs e)
{
this.mainForm.LabelText = txtMessage.Text;
}
}
alt text http://demo.ruchitsurati.net/files/frm1.png
alt text http://demo.ruchitsurati.net/files/frm2.png
Making them Singleton is not a completely bad idea, but personally I would not prefer to do it that way. I'd rather pass the reference of one to another form. Here's an example.
Form1 triggers Form2 to open. Form2 has overloaded constructor which takes calling form as argument and provides its reference to Form2 members. This solves the communication problem. For example I've exposed Label Property as public in Form1 which is modified in Form2.
With this approach you can do communication in different ways.
Download Link for Sample Project
//Your Form1
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frm = new Form2(this);
frm.Show();
}
public string LabelText
{
get { return Lbl.Text; }
set { Lbl.Text = value; }
}
}
//Your Form2
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private Form1 mainForm = null;
public Form2(Form callingForm)
{
mainForm = callingForm as Form1;
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
}
private void button1_Click(object sender, EventArgs e)
{
this.mainForm.LabelText = txtMessage.Text;
}
}
alt text http://demo.ruchitsurati.net/files/frm1.png
alt text http://demo.ruchitsurati.net/files/frm2.png
answered Jan 28 '11 at 0:29
this. __curious_geekthis. __curious_geek
33.9k1997126
33.9k1997126
1
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
7
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
2
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
4
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
2
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
|
show 1 more comment
1
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
7
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
2
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
4
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
2
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
1
1
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
-1, events are a much better solution.
– Ed S.
Jan 28 '11 at 0:33
7
7
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
@EdS. : Are you really downrating a solution because you don't think it's the best solution? I hope not because this is a totally valid and working solution.
– Tipx
Oct 24 '11 at 4:46
2
2
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
While, yes, the solution is valid, I don't believe it is optimal: I do not recommend passing a Form to anything other than a presenter. If you are not using presenters, then use another class in which to pass delegates or pass delegates to the other form. Do not open one form up to abuse by another.
– IAbstract
May 10 '12 at 15:06
4
4
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
@EdS.I agree with Tipx down votes are for incorrect or missleading answer, if you think there is a better answer then upvote it (or provided it if you don't see one), don't punish people for helping
– MikeT
Jun 10 '16 at 9:48
2
2
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
The better solution would be to pass a backing class rather than the form itself as this allows you to share only required functionality, you can then also implement notification events. it also better fits the Binding model
– MikeT
Jun 10 '16 at 9:53
|
show 1 more comment
Access the form's controls like this: formname.controls[Index]
.
You can cast as appropriate control type, Example:DataGridView dgv = (DataGridView) formname.Controls[Index];
add a comment |
Access the form's controls like this: formname.controls[Index]
.
You can cast as appropriate control type, Example:DataGridView dgv = (DataGridView) formname.Controls[Index];
add a comment |
Access the form's controls like this: formname.controls[Index]
.
You can cast as appropriate control type, Example:DataGridView dgv = (DataGridView) formname.Controls[Index];
Access the form's controls like this: formname.controls[Index]
.
You can cast as appropriate control type, Example:DataGridView dgv = (DataGridView) formname.Controls[Index];
edited Feb 6 '18 at 11:24
GntS
4211521
4211521
answered May 31 '17 at 18:03
DwightDwight
196113
196113
add a comment |
add a comment |
There is one more way, in case you don't want to loop through "ALL" controls like Joe Dabones suggested.
Make a function in Form2 and call it from Form1.
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public void SetIndex(int value)
{
lsbMyList.SelectedIndex = value;
}
}
public partial class Form1 : Form
{
public Form2 frm;
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
frm=new Form2();
frm.Show();
}
private void button1_Click(object sender, EventArgs e)
{
frm.SetIndex(Int.Parse(textBox1.Text));
}
}
add a comment |
There is one more way, in case you don't want to loop through "ALL" controls like Joe Dabones suggested.
Make a function in Form2 and call it from Form1.
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public void SetIndex(int value)
{
lsbMyList.SelectedIndex = value;
}
}
public partial class Form1 : Form
{
public Form2 frm;
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
frm=new Form2();
frm.Show();
}
private void button1_Click(object sender, EventArgs e)
{
frm.SetIndex(Int.Parse(textBox1.Text));
}
}
add a comment |
There is one more way, in case you don't want to loop through "ALL" controls like Joe Dabones suggested.
Make a function in Form2 and call it from Form1.
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public void SetIndex(int value)
{
lsbMyList.SelectedIndex = value;
}
}
public partial class Form1 : Form
{
public Form2 frm;
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
frm=new Form2();
frm.Show();
}
private void button1_Click(object sender, EventArgs e)
{
frm.SetIndex(Int.Parse(textBox1.Text));
}
}
There is one more way, in case you don't want to loop through "ALL" controls like Joe Dabones suggested.
Make a function in Form2 and call it from Form1.
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public void SetIndex(int value)
{
lsbMyList.SelectedIndex = value;
}
}
public partial class Form1 : Form
{
public Form2 frm;
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
frm=new Form2();
frm.Show();
}
private void button1_Click(object sender, EventArgs e)
{
frm.SetIndex(Int.Parse(textBox1.Text));
}
}
answered Nov 16 '17 at 2:57
user8931966
add a comment |
add a comment |
It's easy, first you can access the other form like this:
(let's say your other form is Form2
)
//in Form 1
Form2 F2 = new Form2();
foreach (Control c in F2.Controls)
if(c.Name == "TextBox1")
c.Text = "hello from Form1";
That's it, you just write in TextBox1
in Form2
from Form1
.
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
add a comment |
It's easy, first you can access the other form like this:
(let's say your other form is Form2
)
//in Form 1
Form2 F2 = new Form2();
foreach (Control c in F2.Controls)
if(c.Name == "TextBox1")
c.Text = "hello from Form1";
That's it, you just write in TextBox1
in Form2
from Form1
.
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
add a comment |
It's easy, first you can access the other form like this:
(let's say your other form is Form2
)
//in Form 1
Form2 F2 = new Form2();
foreach (Control c in F2.Controls)
if(c.Name == "TextBox1")
c.Text = "hello from Form1";
That's it, you just write in TextBox1
in Form2
from Form1
.
It's easy, first you can access the other form like this:
(let's say your other form is Form2
)
//in Form 1
Form2 F2 = new Form2();
foreach (Control c in F2.Controls)
if(c.Name == "TextBox1")
c.Text = "hello from Form1";
That's it, you just write in TextBox1
in Form2
from Form1
.
edited Feb 8 '18 at 7:43
GntS
4211521
4211521
answered Sep 15 '17 at 13:11
Joe DabonesJoe Dabones
411
411
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
add a comment |
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
A good related subject: stackoverflow.com/a/1499088/4439444
– GntS
Feb 8 '18 at 11:57
add a comment |
protected by Community♦ Nov 28 '12 at 19:42
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Interaction between forms — How to change a control of a form from another form?
– Reza Aghaei
Nov 4 '17 at 21:13