[RESOLVED] Transferring info between forms

[Frobot]

I have my main form, and when you click a button another form pops up.
This 2nd form has some textboxes.
I need to keep track of what gets put into the boxes after the 2nd form gets closed out, and have access to it on the main form.
Should be pretty simple, I'm just not sure what to search for on google to find this out (my usual way of learning new things)

[DataMiser]

Once the 2nd form is closed then the data in the textboxes is lost. You would need to store this data in a manner that would be available to the main form via variables, a class, file, database or other such method that will still hold the data once the form2 object is unloaded.

[Frobot]

I know this but I'm asking how do I store it to a variable that can be used in both forms?
If I make a variable to hold it inside the 2nd form, it's gone too once I close it out.

[Arjay]

See this post...
http://www.codeguru.com/forum/showthread.php?t=514767

[Frobot]

This shows how to make the 2nd form have a value used by the first form when it is opened, but I need for the first form to have a value from the 2nd form after it is closed.
I have found a guide on passing a value from a parent form onto the child form, but I need the opposite.
Making the child form return values to the original form.

[Arjay]

This shows how to make the 2nd form have a value used by the first form when it is opened, but I need for the first form to have a value from the 2nd form after it is closed.

So modify the example. The point of this example is to show how to pass around data between forms and retain the data after one or more forms have closed.

To modify...
In the Ok button handler of the second form, save the data to the singleton class.

In the first form, in the handler that calls ShowDialog() of the second form, read the saved data from the singleton class.

[foamy]

Really, it's quite simple:

Main form

private void button1_Click(object sender, EventArgs e)
{
   Form2 f2 = new Form2();
   if(f2.ShowDialog(this) == DialogResult.OK)
   {
       string value1 = f2.Value1;
       string value2 = f2.Value2;
   }
   f2.Dispose();
}

Form2

public string Value1 {get; private set;}
public string Value2 {get; private set;}

private void buttonOK_Click(object sender, EventArgs e)
{
    this.Value1 = textBox1.Text;
    this.Value2 = textBox2.Text;
    this.DialogResult = DialogResult.OK;
    this.Close();
}

Try it out

[Frobot]

Amazing foamy.
I have tried to follow example after example and none would work, but this one took me maybe 2 minutes to implement.

[Arjay]

That example is an easy way to do it, but what if you want a bit more functionality?

For example, say the user wants to modify the selections in form 2 by opening it again. With the easy example, the user is going to have to start over and reenter all the information.

[Frobot]

I see. It would probably be good to learn both ways, but at least in my case the easy way is all I would need.

[foamy]

K.I.S.S.

If you'd want the user to be able to alter the values, you could simply add the values to Form2's constructor and set the textboxes when opening the form. This way, the user wouldn't need to re-enter anything the second time - no need for anything fancy in my mind

[Arjay]

K.I.S.S.

If you'd want the user to be able to alter the values, you could simply add the values to Form2's constructor and set the textboxes when opening the form. This way, the user wouldn't need to re-enter anything the second time - no need for anything fancy in my mind

The approach I proposed is a little bit like the MV* design patterns and help keep a separation of presentation and data.

Too often folks mistakening have tightly coupled UI by attempting to read data in one form from another. I prefer to have each form completely independent from another form by the form only be aware of its model (or controller/presenter. When I refer to model, I'm also referring to a presenter or controller depending on which design pattern is being used.

The nice thing about the decoupled approach is it's scalable and easy to debug because to test you make sure that each form is able to properly read and write to the model. If each form can do that, then you can avoid any complex hierarchy problems where a child form needs to read or write data from its parent's parent, and other such nightmares.

Understanding this approach will help in the future because this is the way it's done with WPF.

[MrGibbage]

I have a closely related question (at least I *THINK* it is).
How do I pass form controls to another class? If I have 40-some controls on a form, how should I pass them from my main Form2.cs? I thought I could just pass "this" (a Form1 class object), that didn't work. For instance, if I have a method in MyClass prototyped as public static void MyClassMethod(Form1 mainform) {}, I would have thought I would be able to access the form controls as mainForm.myControl, but myControl seems to be out of scope.

[Arjay]

I have a closely related question (at least I *THINK* it is).
How do I pass form controls to another class? If I have 40-some controls on a form, how should I pass them from my main Form2.cs? I thought I could just pass "this" (a Form1 class object), that didn't work. For instance, if I have a method in MyClass prototyped as public static void MyClassMethod(Form1 mainform) {}, I would have thought I would be able to access the form controls as mainForm.myControl, but myControl seems to be out of scope.

Accessing a form's controls from another form leads to tightly coupled code. When you start dealing with forms that can be opened by different forms (or in different hierarchies), it quickly leads to code that can become unmaintanable.

To avoid this, the recommended approach is to use a MV* pattern. However, this take a bit getting one's head around and my be too much for a beginner.

So...

To answer your direct question, make the controls public (rather than protected). Or expose public accessor properties.

[TheGreatCthulhu]

Or expose public accessor properties.

Or use the Controls property - but you'll have to do some type-casting and dig through the elements a bit to find the controls contained in other controls (like in panels, group-boxes...).