Transferring information between two forms, Part 2: Child to Parent

• Download DataBetweenForms.zip - 42.1 KB

Introduction

It's a common problem. How do you transfer data between two forms in a Windows Forms application? And it's really easy to do. But...there are too many people out there that will tell you to just "make the control public" and set the value. Unfortunately that's a very bad idea - and the proper way is not a lot more complex.

This could have been an article, but I wanted to keep it focused (because this is information for a beginner  and felt that a tip for each of the common transfers might work better.  

So, a set of three Tips: 

Part1: Parent to Child Transferring information between two forms, Part 1: Parent to Child[^]

• Covers transferring data from a Parent form to it's Child form when the Parent want's to.

• Covers transferring data from the Child to the Parent when the Child wants to. 

• Covers transferring data from a Child to another Child when the first Child wants to. 

Background  

If "making the control public" works, why is is it private by default? Why not do that and move on? It's easy to do and it works!

The answer is that when you do that, you are exposing the internals of your form to the whole world - and that is not a good idea, because:

1. It's against the principles of OOPs 
2. It locks the design of the two forms together - you can't change one form without considering it's effects on the other.  Suppose you have a TextBox in a child, and  you make it public. You now can't change it to any other control (or do anything with it at all, pretty much) because it might break the form that is using it. This makes your life a lot harder when you have a small change to make, because suddenly it's a small change to the child, and a massive set of changes to the parent.
3. When you make a control public, you don't just expose the field you want: myTextBox.Text. Oh, no - you expose them all. Font, Size, Location, BackColor, then lot. And there is nothing stopping any external class from changing them, while your form is running. Nasty...

Using the code 

There are three basic ways that data needs to be transferred: this tip covers when the Child wants to change data on its Parent. This is a more complex operation than going from the Parent to the Child, but the way that is often suggested is to create a Parent Form reference in the Child and set that when the Child is created. It can then access the parent and do what it has to.

The problem with that approach is that it's even worse than making your control public: it ties the two forms together much, much more tightly - now the Parent has to know about the Child, and the Child has to know about the Parent. Which means that you can't reuse the Child form from a different type of parent, or without a parent altogether. And that's bad - because if you create a form for changing the details of your Widget class, you will probably want to use it from the "NewWidget" form, and your "EditWidget" form. If your Widget Details form is hard coded to expect a "NewWidget" form, then it won't work with an "EditWidget" and you end up duplicating work with all the opportunities for error that that provides.

Instead, use the Event method to let the Child tell the Parent there is data to work with. 

The Event method  

This is really simple: you create a property in the Child to supply the data, and an Event to say the data is available. The Parent handles the Event, fetches the data and does with it what it wants.

Child Form property

/// <summary>
/// Data to transfer into / out of form
/// </summary>
public string Data
    {
    get { return tbData.Text; }
    set { tbData.Text = value; }
    }

Child Form Event

/// <summary>
/// Event to indicate new data is available
/// </summary>
public event EventHandler DataAvailable;
/// <summary>
/// Called to signal to subscribers that new data is available
/// </summary>
/// <param name="e"></param>
protected virtual void OnDataAvailable(EventArgs e)
    {
    EventHandler eh = DataAvailable;
    if (eh != null)
        {
        eh(this, e);
        }
    }

Then all the Child form has to do is signal the Event to indicate the data is ready. In this case, we will do it when the user presses a button.

/// <summary>
/// Tell the parent the data is ready.
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void butTransfer_Click(object sender, EventArgs e)
    {
    OnDataAvailable(null);
    }

The parent form just has to add the handler when it creates the form instance:

// Add a child form
frmChild child = new frmChild();
child.DataAvailable += new EventHandler(child_DataAvailable);
child.Data = "Hello child 1 from the Parent!";
child.Show();

And the Parent handles the Event to fetch the data, and in this case displays it in a TextBox:

/// <summary>
/// The child has data available - get it.
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
void child_DataAvailable(object sender, EventArgs e)
    {
    frmChild child = sender as frmChild;
    if (child != null)
        {
        tbData.Text = child.Data;
        }
    }

In this case, we don't even need to save the Child form instance, because the Event mechanism passes it to the Parent when the event occurs.

The information could easily be transferred with the Event by creating a custom EventArgs, but in most cases that isn't necessary. 

History

• 2013-02-18: First version 
• 2013-02-19: Added links to other tips in series  
• 2013-04-03: Corrected spelling error in title: "Transfering" should have been "Transferring"  
• 2013-04-03 Corrected the same spelling error in the links to companion tips...