How to access a form control for another form?












9














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?










share|improve this question
























  • Interaction between forms — How to change a control of a form from another form?
    – Reza Aghaei
    Nov 4 '17 at 21:13
















9














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?










share|improve this question
























  • Interaction between forms — How to change a control of a form from another form?
    – Reza Aghaei
    Nov 4 '17 at 21:13














9












9








9


2





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?










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












5 Answers
5






active

oldest

votes


















2














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.






share|improve this answer





















  • 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





















21














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






share|improve this answer

















  • 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





















2














Access the form's controls like this: formname.controls[Index].

You can cast as appropriate control type, Example:
DataGridView dgv = (DataGridView) formname.Controls[Index];






share|improve this answer































    1














    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));
    }
    }





    share|improve this answer





























      1














      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.






      share|improve this answer























      • A good related subject: stackoverflow.com/a/1499088/4439444
        – GntS
        Feb 8 '18 at 11:57










      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









      2














      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.






      share|improve this answer





















      • 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


















      2














      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.






      share|improve this answer





















      • 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
















      2












      2








      2






      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.






      share|improve this answer












      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.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      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




















      • 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















      21














      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






      share|improve this answer

















      • 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


















      21














      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






      share|improve this answer

















      • 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
















      21












      21








      21






      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






      share|improve this answer












      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







      share|improve this answer












      share|improve this answer



      share|improve this answer










      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
















      • 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













      2














      Access the form's controls like this: formname.controls[Index].

      You can cast as appropriate control type, Example:
      DataGridView dgv = (DataGridView) formname.Controls[Index];






      share|improve this answer




























        2














        Access the form's controls like this: formname.controls[Index].

        You can cast as appropriate control type, Example:
        DataGridView dgv = (DataGridView) formname.Controls[Index];






        share|improve this answer


























          2












          2








          2






          Access the form's controls like this: formname.controls[Index].

          You can cast as appropriate control type, Example:
          DataGridView dgv = (DataGridView) formname.Controls[Index];






          share|improve this answer














          Access the form's controls like this: formname.controls[Index].

          You can cast as appropriate control type, Example:
          DataGridView dgv = (DataGridView) formname.Controls[Index];







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Feb 6 '18 at 11:24









          GntS

          4211521




          4211521










          answered May 31 '17 at 18:03









          DwightDwight

          196113




          196113























              1














              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));
              }
              }





              share|improve this answer


























                1














                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));
                }
                }





                share|improve this answer
























                  1












                  1








                  1






                  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));
                  }
                  }





                  share|improve this answer












                  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));
                  }
                  }






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 16 '17 at 2:57







                  user8931966






























                      1














                      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.






                      share|improve this answer























                      • A good related subject: stackoverflow.com/a/1499088/4439444
                        – GntS
                        Feb 8 '18 at 11:57
















                      1














                      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.






                      share|improve this answer























                      • A good related subject: stackoverflow.com/a/1499088/4439444
                        – GntS
                        Feb 8 '18 at 11:57














                      1












                      1








                      1






                      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.






                      share|improve this answer














                      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.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      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


















                      • 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





                      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?



                      Popular posts from this blog

                      What visual should I use to simply compare current year value vs last year in Power BI desktop

                      Alexandru Averescu

                      Trompette piccolo