Using The Controls Of One Form Into Another

Question

I have a application that in one form(Form1) I have many checkBoxes and textBoxes and in Form2 I have only a textBox, but I want to put some contents from the Form1 textBoxes and put in the Form2 textBox, like this, but between forms:

textBox1.Text = "Test: " + textBox1 + "\n" + textBox3;

As textBox1 in Form2 and the second textBox1 and textBox3 in Form1, but how I can do this? Thanks.

Answer 1

Depending on how you launch the second form you can either assign a member object in Form2 that references Form1 or if you are using an MDI interface there is a forms collection from which you can retrieve a reference to your Form1.

For example, you could have the following code in your Form2 class:

public partial class Form2 : Form
{
    public Form1 LaunchOrigin { get; set; }
    // and so on

Now you can assign the LaunchOrigin member when you launch Form2. Here is an example:

Form2 newForm = new Form2();
newForm.LaunchOrigin = this;
newForm.Show();

You now have access to Form1 and all its members. Here is a simple example of that:

    private void Form2_Load(object sender, EventArgs e)
    {
        this.Text = LaunchOrigin.Text;
    }

You must remember that controls are declared as private so you won't have direct access to them. You could write a property on Form1 that referenced that control but this is most often a bad idea. For the sake of completeness, however, here is some code that you could use to expose a button on Form1:

public partial class Form1 : Form
{
    public Button theButton;
    public Form1()
    {
        InitializeComponent();
        theButton = button1; // where button1 is what I dragged on
    }
    // and so on

Although what you're asking is relatively easy to accomplish, it puts you on the road to some brittle application structure. Think hard about what it is you're trying to expose between forms, perhaps it deserves to be a distinct type that you can bind to both forms so that once you change the underlying type, you change the representation on both.

Answer 2

There are decent ways to do this and ugly ways to do this... starting with the UGLY:

1. One of the ugliest would be to pass a reference to Form1 into Form2's constructor and then store that reference as a field for later. It's nasty because it creates a very tight coupling between the two. Changing Form1's interface or behavior affects Form2.

2. A less ugly, but still hackish, way to do this would be pass the string values from Form1 into Form2's constructor - or some public/internal method on Form2. You still have the dependency around those strings, but at least it's not a complete coupling of Form1 and Form2. It's just an expectation that Form2 will always have a Form1 to feed it these strings.

... fill in some more nasty variations here.

I suggest you look into an app-wide solution that solves this problem and doesn't create the inter-objec dependencies.

Create a messaging interface that works on a lightweight "pub/sub" -- or publish/subscribe -- model. The idea is that you have some components in your app that publish messages (your string values - or something more complex) and other components in your app that subscribe to messages.

When Form 1 starts up, it'd register with the messaging interface "Hey, I'm gonna publish messages of this type" (where the type is some indicator your provide). When Form 2 starts up, it registers with the messaging interface saying "Yo, when someone publishes a message of this type, pass it to me".

Both the publisher and subscriber implement some known interface so that your message handler can talk to them (IPublisher, ISubscriber) -- and receive/send the messages. There's no reason one component can be both a publisher and subscriber, if warranted (essentially treating the objects in a system as "peers" or "colleagues") A few MessageReceived events and some code to manage a collection of publishers/subscribers and you're good to go.

For more detail, check out the Mediator pattern which describes this type of solution in more detail.