Problem with value passing

  • Thread starter Thread starter yo_mismo
  • Start date Start date
Y

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.
 
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.
 
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;
}
}
Click to expand...

Why?
 
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.
 
Kai Brinkmann said:
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.
Click to expand...

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
Click to expand...

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.... :)
Click to expand...

Flaming is for those who can't think. :)
 
Scott Roberts said:
Says who? And more importantly, why?
Click to expand...

Says most OO practitioners, and for the reaons below.
Yes, but the code you posted does none of that.
Click to expand...

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).
Click to expand...

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.
 
1) You're forced to recompile all code using the class
Click to expand...

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.
Click to expand...

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.
Click to expand...

Good point. I don't use much reflection or serialization personally, but
that doesn't mean others don't.
 
Scott Roberts said:
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!
Click to expand...

External assemblies. If they're trying to access it as a field and it's
now a property, that's a breaking interface change.
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.
Click to expand...

I wouldn't expect it to either - because I'd never expose the field...
Good point. I don't use much reflection or serialization personally, but
that doesn't mean others don't.
Click to expand...

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.
 
Back
Top