Ah, well...this is worse than you think!
First of all, let's clear up the difference between DECLARE and INSTANTIATE and DEFINE.
You DECLARE a variable that *may or may not* reference an object of the type it is declared as.
Foo f = null; // f is declared as a reference to an object of type Foo
You INSTANTIATE an object by using the
new operator:
new Foo( ); // an object is created!
And you DEFINE a value for the already-declared variable
f by assigning that instantiated object to the variable, as in:
f = new Foo( );
Finally, you *can* do all 3 of these *separate and distinct actions* in one statement in C# (and in most languages, but not all). In C#, you simply do
Foo f = new Foo( );
Okay?
Now to your problem...
When you run the code from Form1.cs, you instantiate an instance of the Form1 object.
When you run the code from Form2.cs, your instantiate an instance of the Form2 object.
BUT WHERE IS THE *REFERENCE* to each of those FORM objects????
If there isn't any "outer" object that has a variable that references each of the objects, then THOSE OBJECTS DON'T EXIST when their execution is finished!
So no matter WHAT the scope of any variable, no matter how the objects referenced by those variable were created, neither the Form *NOR THOSE OBJECTS* still exists when the execution completes.
Now, I need to tell you that I am *NOT* a Windows Forms programmer, at all. ASP.NET, yes. Java, both in JSP and in standalone, yes. So here we get into the range of speculation.
I am *assuming* that in a Windows Forms application, there is some outer control module (instance of a control class, one assumes) the is executed when you run "myWinFormProgram.exe".
And almost surely it is that "control module" that is responsible for moving the user from one form to another. Meaning it instantiates a Form1 object or a Form2 object, as needed.
And that means the ONE way you can communicate between Form1 and Form2 is to use an object reference that is independent of either of them. An object reference in the "control module." In short, a reference that is "higher in the hierarchy."
BUT...
Experimentation is a wonderful thing.
THERE IS ANOTHER WAY TO DO THIS.
As I said, I'm not a Windows Forms person, but I happen to have VS 2003 here, so I tried using it to create a WinForms project in C#.
And it occurred to me that in any form based project, you are going to have one "master form" that controls all the other forms. And naturally, this would normally be the first form created, the "Form1.cs" that you get by default.
So if Form1 is used to invoke Form2, by doing something like
Form2 f2 = new Form2( );
then that means that Form1 will *always* be "alive" (still in memory) when the code in Form2.cs is executing.
Okay, so just make the desired members of Form1 public!!!
I did this by dragging a textbox and a button onto Form1. Then I changed the declaration of the textbox from
private System.Windows.Forms.TextBox textBox1;
to
public System.Windows.Forms.TextBox textBox1;
And then I also dragged a textbox onto Form2 and then changed the contructor for Form2 to this:
Code:
private Form1 f1 = null; // added this, too
public Form2(Form1 f)
{
InitializeComponent();
f1 = f;
// And this next line could be here *OR* it could be
// any place in the rest of the code for Form2!
// It simply copies from Form1's text box to Form2's text box.
textBox1.Text = f1.textBox1.Text;
}
And, finally, I used this code for the button click in Form1:
Code:
private void button1_Click(object sender, System.EventArgs e)
{
Form2 f2 = new Form2(this);
}
And VOILA! When the button is clicked, a new Form2 object is created, and the text from button1 in the Form1 object is copied--BECAUSE IT IS NOW PUBLIC it can be!--to the text box in the Form2 object.
[Okay, what I don't know how to do is to then cause the Form1 display to disappear and have the Form2 display then appear in its place. Like I said, not a Windows Forms person.]
But the point is, by passing a reference "to myself" (the
this in the button1_Click method) to Form2 when it is created, all public members of myself (Form1) are now accessible to Form2 by way of that passed reference (that I stored in a reference variable in Form2).
PHEW! Does all that make sense???
There may be better ways to pass around object references in a windows form app. I notice that all the forms are in the same namespace (namespace WindowsApplication1, by default), so you could also have an independent class that holds all your public data. You'd instantiate that in the starting form and pass a reference to it to all your other forms and/or utility code.
Anyway, I guess my experimentation showed me that, by default, a C# WinForm project really *does* have the initial instantiation of Form1.cs (or whatever you rename it to) as the top level object in the executable code. Which does simplify some things. (E.g., you can put all the stuff you want to share amongst all other forms in Form1.cs as public members, so long as you then pass a reference to Form1 to the other objects.)
At this point in time, I'll pass the buck to Dr. Purdum, but I'd bet that he suggests that you go buy his book. As you should.
Scope of Objects
