Get set doesn't return value that I expected

[queanbeyan]

Hi

I am working through some trivial examples using properties and using
'get' and 'set', but I dont seem to return the value that i expect.
this code below runs but when I click on the button I expect to have
the text that was put in the tbInput box copied to the tbOutput box.
But I only get a blank.. I have looked in the locals in visual studio
but dont see that the value on tbInput.text is passed to the input or
Input string.

Any help appreciated.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace getset
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private string input;
public string Input
{
get
{
return input;
}
set
{
input = tbInput.Text;
}
}

private void btnGet_Click(object sender, EventArgs e)
{

tbOutput.Text=input;

}
}
}

 

[Marc Gravell]

get {return input;}

set {input = tbInput.Text;}

looks like an error, as you ignore "value" (the value being passed into
the "set"). If you want "Input" to represent the value in tbInput, then
you don't need a backing field at all.

tbOutput.Text=input;

looks like a minor error; recommended to use the properties even within
the class unless good reasons not to; makes it easier to avoid
copy/paste etc bugs (remember the getter is often inlined by the JIT
anyway).

So I would probably expect (based on my above assumptions):
get {return tbInput.Text;}
set {tbInput.Text = value;}
tbOutput.Text=Input;

Marc

 

[Stephany Young]

That's close Marc .. but the point is that the set accessor of the Input
property is never called.

The OP's code would work if it was:

Input = ""; // the value assigned to the property is irrevelant because it
is overridden.

tbOutput.Text=Input;

Although, in this case it would be ridiculous to override the incoming value
in the set accessor, it is perfectly valid if one really wanted to do i that
way.

The question I would have to ask Is why do something like this when all one
is doing is wrapping pre-existing properties without adding any value to
wrapper? After all, it is is as simple as:

tbOutput.Text = tbInput.Text;

 

[Marc Gravell]

With the code ass posted, it wouldn't matter if it *was* called; the
"get" still wouldn't return the same value. With the code as I
suggested, it doesn't matter whether Input is explicitely set or not;
it returns the current value of the tbInput.Text; but I agree: the
only /real/ benefit to a property approach here would be to expose
this to external callers. I made the implicit assumption that all of
the above was as per to OP: "working through some trivial examples
using properties and using 'get' and 'set'", in which case the code I
posted is perfectly valid and correct to my not-yet-fully-caffeined-up
eye.

Marc

 

[Bobbo]

The question I would have to ask Is why do something like this when all one
is doing is wrapping pre-existing properties without adding any value to
wrapper? After all, it is is as simple as:

tbOutput.Text = tbInput.Text;

The OP's objective appears to be to experiment with properties and
accessors rather than just copy the value of a textbox.