Problem with value passing

[yo_mismo]

Hi,

I send a parameter from a Form (Form1) to an other form (Form2):

Form2 frm2 = new Form2();
frm2.number_frm2 = number_frm1;
frm2.Show();

The problem i got is that the variable 'number_frm2' always have the value 0
(it's an integer). I have declared it as 'public' but i can't get the right
value. I hope someone can help me, thanks.

[Kai Brinkmann [MSFT]]

What is number_frm1 and where is it set? If it's a public member of an
instance of your Form1 class, you need to specify that. For example:

frm2.number_frm2 = frm1.number_frm1;

Also, you should use properties rather than exposing member variables of
your classes directly. For example, in Form1:

private int number_frm1;

// some code to assign a value to number_frm1

public int Number {
get {
return number_frm1;
}
set {
number_frm1 = value;
}
}

You can omit the set accessor if you want this value to be read-only. In
either case, you can then use the following to access this variable in
Form2:

frm2.number_frm2 = frm1.Number;

Hope this helps.

--
Kai Brinkmann [MSFT]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"yo_mismo" <qw*@rty.com> wrote in message
news:hA******************@news.ono.com...

Hi,

I send a parameter from a Form (Form1) to an other form (Form2):

Form2 frm2 = new Form2();
frm2.number_frm2 = number_frm1;
frm2.Show();

The problem i got is that the variable 'number_frm2' always have the value
0
(it's an integer). I have declared it as 'public' but i can't get the
right
value. I hope someone can help me, thanks.

[Scott Roberts]

"Kai Brinkmann [MSFT]" <ka******@online.microsoft.com> wrote in message
news:Ob**************@TK2MSFTNGP14.phx.gbl...

Also, you should use properties rather than exposing member variables of
your classes directly. For example, in Form1:

private int number_frm1;

// some code to assign a value to number_frm1

public int Number {
get {
return number_frm1;
}
set {
number_frm1 = value;
}
}

Why?

[Kai Brinkmann [MSFT]]

Oh my, now you've gone and opened that can of worms again :) To be sure,
opinions on the use of properties do differ widely. I happen to think they
are a good idea for a number of reasons:

1. It's good programming practice to limit direct access to data fields from
outside the class.
2. You can make properties read-only by not providing a set accessor. (Of
course you could also use a readonly field.)
3. You can perform additional calculations inside your accessors. For
example, you could perform data validation inside the set accessor.
4. You can easily notify other classes/objects about state changes
5. Versioning

To be sure, properties aren't perfect (for example, it would be nice to have
overloaded get/set accessors and/or different access modifiers), but I
generally find them more useful than public instance fields.

Let the flamewars begin.... :)

--
Kai Brinkmann [MSFT]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Scott Roberts" <sc***********@no-spam.intelebill.com> wrote in message
news:O2**************@TK2MSFTNGP09.phx.gbl...

"Kai Brinkmann [MSFT]" <ka******@online.microsoft.com> wrote in message
news:Ob**************@TK2MSFTNGP14.phx.gbl...

Also, you should use properties rather than exposing member variables of
your classes directly. For example, in Form1:

private int number_frm1;

// some code to assign a value to number_frm1

public int Number {
get {
return number_frm1;
}
set {
number_frm1 = value;
}
}

Why?

[Scott Roberts]

"Kai Brinkmann [MSFT]" <ka******@online.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Oh my, now you've gone and opened that can of worms again :)
:-)
1. It's good programming practice to limit direct access to data fields from outside the class.
Says who? And more importantly, why?
2. You can make properties read-only by not providing a set accessor. (Of
course you could also use a readonly field.)
3. You can perform additional calculations inside your accessors. For
example, you could perform data validation inside the set accessor.
4. You can easily notify other classes/objects about state changes
5. Versioning
Yes, but the code you posted does none of that.

Here's the crux of my question, compare the following:

Your code:

private int number_frm1;

public int Number {
get {
return number_frm1;
}
set {
number_frm1 = value;
}
}
My code:

public int Number;
In what way(s) do these differ? In what way(s) and for what reason(s) is one
"better" than the other. Keep in mind that, if necessary, my code can always
be modified to look exactly like yours at any future date without any
side-effects (other than those I intend, of course, through the
implementation of a getter/setter).
Let the flamewars begin.... :)

Flaming is for those who can't think. :)

[Jon Skeet [C# MVP]]

Scott Roberts <sc***********@no-spam.intelebill.com> wrote:

1. It's good programming practice to limit direct access to data fields
from outside the class.
Says who? And more importantly, why?

Says most OO practitioners, and for the reaons below.

2. You can make properties read-only by not providing a set accessor. (Of
course you could also use a readonly field.)
3. You can perform additional calculations inside your accessors. For
example, you could perform data validation inside the set accessor.
4. You can easily notify other classes/objects about state changes
5. Versioning

Yes, but the code you posted does none of that.

Not yet - but the code with the property can be changed to do any of
those (except making it readonly) without changing the interface used
by other code. The public field way of doing things can't.
Here's the crux of my question, compare the following:

Your code:

private int number_frm1;

public int Number {
get {
return number_frm1;
}
set {
number_frm1 = value;
}
}
My code:

public int Number;

In what way(s) do these differ? In what way(s) and for what reason(s) is one
"better" than the other. Keep in mind that, if necessary, my code can always
be modified to look exactly like yours at any future date without any
side-effects (other than those I intend, of course, through the
implementation of a getter/setter).

No, there are side-effects:

1) You're forced to recompile all code using the class
2) Any code which uses the field as a ref or out parameter would no
longer compile.
3) Any code which assumes that it's a field (using reflection, possibly
serialization etc) breaks.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

Scott Roberts <sc***********@no-spam.intelebill.com> wrote:

1. It's good programming practice to limit direct access to data fields
from outside the class.

Says who? And more importantly, why?

Says most OO practitioners, and for the reaons below.

Oops, I meant to say before: also says Microsoft:

http://msdn.microsoft.com/library/en-
us/cpgenref/html/cpconFieldUsageGuidelines.asp?frame=true

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Scott Roberts]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

1) You're forced to recompile all code using the class
I don't follow you. Are you referring to code in the same assembly that uses
the class? Of course you have to recompile the entire assembly if you change
the field, just as you would if you changed the getter/setter of a property.

Or do you mean you have to recompile external assemblies if you change a
field into a property? If so, I wasn't aware of this and it's good info to
have!
2) Any code which uses the field as a ref or out parameter would no
longer compile.
Good point. I would not expect code to use an object field/property as a ref
or out parameter, but I suppose it's possible.
3) Any code which assumes that it's a field (using reflection, possibly
serialization etc) breaks.

Good point. I don't use much reflection or serialization personally, but
that doesn't mean others don't.

[Jon Skeet [C# MVP]]

Scott Roberts <sc***********@no-spam.intelebill.com> wrote:

1) You're forced to recompile all code using the class

I don't follow you. Are you referring to code in the same assembly that uses
the class? Of course you have to recompile the entire assembly if you change
the field, just as you would if you changed the getter/setter of a property.

Or do you mean you have to recompile external assemblies if you change a
field into a property? If so, I wasn't aware of this and it's good info to
have!

External assemblies. If they're trying to access it as a field and it's
now a property, that's a breaking interface change.

2) Any code which uses the field as a ref or out parameter would no
longer compile.

Good point. I would not expect code to use an object field/property as a ref
or out parameter, but I suppose it's possible.

I wouldn't expect it to either - because I'd never expose the field...

3) Any code which assumes that it's a field (using reflection, possibly
serialization etc) breaks.

Good point. I don't use much reflection or serialization personally, but
that doesn't mean others don't.

Another handy feature of properties is that it's really easy to find
out when they're being used during debug sessions - you can stick break
points on property accesses, but you can't do the same to find every
time a field is being used.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too