Passing information between Forms--is there any other way than usingparametized constructors?

[raylopez99]

This thread is about how variables or parameters (including objects)
are passed between forms (namely, using parameterized constructors,
e.g., to pass an int between forms (e.g., a calling form and a called
dialog form) (see below).

My question is that though this works fine, and is consistent with
everything I learned in C++, is there a 'better' way to pass
information, including member variables, objects, and the like, other
than using a parametized constructor as below?

Just to clarify: I don't believe a global variable is a 'better' way,
so that way is excluded.

RL

====calling form, has this somewhere in an event trigger procedure
where you want to call the called form:

int kay = myClass.SomeProperty;

Form2MyWinForm myForm01 = new Form2MyWinForm(kay); //a
parametized constructor, since parameter int 'kay' is passed

myForm01.Show(); //shows the called form

====called form (dialog), has this parametized normal constructor:

public partial class Form2MyDialogBox : Form
{
int F2MDBint;

public Form2MyDialogBox(int j) //parameterized instance
constructor, takes an 'int', which is therefore passed from calling to
called form.
{
InitializeComponent();
F2MDBint = j;
}
///

 

[Jeff Winn]

Create a public property on the child form you access from the parent.

public partial class Form2 : Form {
int _myInt;

public Form2() {
this.Initialize();
}

public int MyInt {
get { return this._myInt; }
set { this._myInt = value; }
}

public string MyText {
get { return this.myTextBox.Text; }
set { this.myTextBox.Text = value; }
}
}

Example of the code that would create the form:

Form2 frm = new Form2();
frm.MyInt = 111;
frm.MyText = "Hello world!";
frm.Show();

I'm not a huge fan of creating gigantic constructors. I usually limit the
arguments on a constructor to those absolutely necessary for the object to
function correctly. If the above example must have MyInt to work correctly,
I'd create an argument for it in the constructor, otherwise I'd leave it as
a property. Also, if you're need to update a control on the child form from
an exposed property you can do so quite easily so long as your object calls
the Initialize method on the form in the constructor (if you're using Visual
Studio).

 

[zacks]

This thread is about how variables or parameters (including objects)
are passed between forms (namely, using parameterized constructors,
e.g., to pass an int between forms (e.g., a calling form and a called
dialog form) (see below).

My question is that though this works fine, and is consistent with
everything I learned in C++, is there a 'better' way to pass
information, including member variables, objects, and the like, other
than using a parametized constructor as below?

Just to clarify:  I don't believe a global variable is a 'better' way,
so that way is excluded.

RL

====calling form, has this somewhere in an event trigger procedure
where you want to call the called form:

        int kay = myClass.SomeProperty;

            Form2MyWinForm myForm01 = new Form2MyWinForm(kay); //a
parametized constructor, since parameter int 'kay' is passed

            myForm01.Show();  //shows the called form

====called form (dialog), has this parametized normal constructor:

    public partial class Form2MyDialogBox : Form
    {
        int F2MDBint;

        public Form2MyDialogBox(int j) //parameterized instance
constructor, takes an 'int', which is therefore passed from calling to
called form.
        {
            InitializeComponent();
            F2MDBint = j;
        }
///

It's just my personal opinion, but I do not like to use parameterized
form constructors. The only time I even use class constructors with
parameters is when I need to set up some overloads.

I prefer to pass data to another form via properties.

And, AFAIK, C#.NET doesn't even support true global variables anyway.

 

[.\\\\axxx]

Create a public property on the child form you access from the parent.

I'm not a huge fan of creating gigantic constructors. I usually limit the
arguments on a constructor to those absolutely necessary for the object to
function correctly. If the above example must have MyInt to work correctly,
I'd create an argument for it in the constructor, otherwise I'd leave it as
a property. Also, if you're need to update a control on the child form from
an exposed property you can do so quite easily so long as your object calls
the Initialize method on the form in the constructor (if you're using Visual
Studio).

I'd also add that, if both forms require acess to a number of shared
values, it may be worthwhile creating an object which is passed (via a
parameterised constructor in the child form).
The advantage here is that - assuming the parent form wants to know
about values changed in the child - it has access to the object
'immediately' - i.e. without having to access parameters on the child
form.
I also am not a fan of exposing controls on child forms - much better
(IMHO) to expose a property which is of relevant type - but not of the
actual control type (e.g. a string property ratherthan a TextBox
propertyif the parent wants to set the child's textBox's .Text
property. This abstraction allows the child form to be changed (e.g.
to use a label instead of a textbox) without the need to change the
parent form at all.

 

[raylopez99]

Create a public property on the child form you access from the parent.

Thanks, that was nice and easy.

RL

 

[raylopez99]

It's just my personal opinion, but I do not like to use parameterized
form constructors. The only time I even use class constructors with
parameters is when I need to set up some overloads.

I prefer to pass data to another form via properties.

That's interesting. I wonder why it's a personal preference, except
for the fact that constructors are maybe more inflexible since they
are only run once, during instantiation, while properties can be set
and get anytime.

And, AFAIK, C#.NET doesn't even support true global variables anyway.

That's interesting, I did not know that. Somebody said properties are
the new global variables, but I guess they meant it as hyperbole.

RL