Here's a different type of solution that shares access to one-and-only-one private method in Form1 in a way it can be called from Form2.
Consider in Form1 you have a TextBox, 'textBox1:
public delegate void MyFunctionExposed();
public static MyFunctionExposed mfX;
private void MyFunction()
{
textBox1.Text = "MyFunction on Form1 called";
}
Form2 f2 = new Form2();
private void Form1_Load(object sender, EventArgs e)
{
f2.Show();
mfX = MyFunction;
}
Now, on Form2 which has only a Button, 'button1:
private void button1_Click(object sender, EventArgs e)
{
Form1.mfX();
}
Discussion:
1. I believe the minimal amount of "exposure" between objects in different Forms/Clases is a good thing in terms of OO design (separation of concerns). One solution above gives Form2 complete access to everything inside Form1: that will work, but is that "mixing" of total access potentially a source of confusion and errors: some think so. My nickname for solutions that provide some small class access to wide functionality in other classes ... that is not related to the purpose of the small class: "tail wags dog" code :)
2. another valid solution idea described above is provided in the idea of a common class, shared by all forms that implements data or methods needed by all or many Forms.
One strategy is to make that shared class static: there are other scenarios where that shared class must be dynamic, and there you have some interesting complications in terms of making sure ... if there's more than one instance of the shared class ... that the "correct one is being used."
And, to make it more interesting, that shared class could be both dynamic (i.e., created via 'New), and yet have certain static methods or whatever in it.
But, "one size never fits all," even though feet do stop growing after a while :)
Missing from this discussion is any idea of using interfaces, but SAK, I am sure, will take care of that. And ... uh oh ... we left out using Events !