Get and Set Property in VS2005

[=?Utf-8?B?Umljaw==?=]

I have a main for frmMain and another form formTest.
I want to set a value of a property in frmMain and then access that value in
frmTest.
I am able to set the property in frmMain as:
MyClass myClass = new MyClass();
myClass.MyProperty = "My New Value";

But, I can't retrieve this value in frmTest; this returns blank:
MyClass myClass = new MyClass();
string MyReturnedValue = myClass.MyProperty;

How do I do it?

******** sample class *********
using System;
using System.Collections.Generic;
using System.Text;
namespace MyApplication
{
class MyClass
{
private string myPropertry;
public string MyProperty
{
get { return myPropertry; }
internal set { myPropertry = value; }
}
}
}

[Peter Duniho]

On Tue, 28 Oct 2008 16:34:00 -0700, Rick <Ri**@discussions.microsoft.com>
wrote:

I have a main for frmMain and another form formTest.
I want to set a value of a property in frmMain and then access that
value in
frmTest.
I am able to set the property in frmMain as:
MyClass myClass = new MyClass();
myClass.MyProperty = "My New Value";

But, I can't retrieve this value in frmTest; this returns blank:
MyClass myClass = new MyClass();
string MyReturnedValue = myClass.MyProperty;

How do I do it?

The property is an instance property, and so if you expect to get the same
value you set, you need to get the value from the same instance on which
you set the property.

You're using two different instances, so of course you don't get the value
you set.

You didn't used to write .NET code with VB.NET, did you? That mistake is
remarkably common for people who are used to VB.NET and just learning C#.
VB.NET has some implicit instance behaviors that can lead to
misunderstandings when using C#, which requires you to be explicit about
what object you're using.

Pete

[Lee]

If you are using MyClass to transfer values, create the properties as
static. You can then set and retrieve these values without the need
to create an instance of the object (using the 'new' command)

Using static saves memory since you do not have to create an instance
of every class to use its values, but you must remember that the
values you set are global to the object. If you change the values
anywhere, that change will be reflected everywhere.

declare:
static public string MyProperty

then you set it like:
MyClass.MyProperty = "My New Value";

and get it like:
string MyReturnedValue = MyClass.MyProperty;

and everything will work just fine.

L. Lee Saunders
http://oldschooldotnet.blogspot.com

[Peter Duniho]

On Tue, 28 Oct 2008 20:52:31 -0700, Lee <sa******@hotmail.comwrote:

If you are using MyClass to transfer values, create the properties as
static. You can then set and retrieve these values without the need
to create an instance of the object (using the 'new' command)

Using static saves memory since you do not have to create an instance
of every class to use its values, but you must remember that the
values you set are global to the object. If you change the values
anywhere, that change will be reflected everywhere.

declare:
static public string MyProperty

then you set it like:
MyClass.MyProperty = "My New Value";

and get it like:
string MyReturnedValue = MyClass.MyProperty;

and everything will work just fine.

Only if it's okay for every use of the property to access the same value.

In most cases, when someone declares a property as an instance member,
it's important for the property to actually be per-instance. In that
case, making the property static would be wrong.

More generally, the question of "static" versus "instance" is almost never
about saving memory and is never about resolving some unexpected behavior
due to failure to understand how instance members work. It's about
knowing whether something makes sense as a per-instance member or not.

Pete

[xcal]

" It's about knowing whether something makes sense as a per-instance member or not."

hi Peter,

I believe that the "this command" should be used allways,
i.e. to use
this.member1
this.property1
etc
because doing so would solve any
per-instance member issues, am I correct ?

regards, Carlos.

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Tue, 28 Oct 2008 20:52:31 -0700, Lee <sa******@hotmail.comwrote:

If you are using MyClass to transfer values, create the properties as
static. You can then set and retrieve these values without the need
to create an instance of the object (using the 'new' command)

Using static saves memory since you do not have to create an instance
of every class to use its values, but you must remember that the
values you set are global to the object. If you change the values
anywhere, that change will be reflected everywhere.

declare:
static public string MyProperty

then you set it like:
MyClass.MyProperty = "My New Value";

and get it like:
string MyReturnedValue = MyClass.MyProperty;

and everything will work just fine.

Only if it's okay for every use of the property to access the same value.

In most cases, when someone declares a property as an instance member,
it's important for the property to actually be per-instance. In that
case, making the property static would be wrong.

More generally, the question of "static" versus "instance" is almost never
about saving memory and is never about resolving some unexpected behavior
due to failure to understand how instance members work. It's about
knowing whether something makes sense as a per-instance member or not.

Pete

[Peter Duniho]

On Wed, 29 Oct 2008 03:26:15 -0700, xcal <[e-mail]:

" It's about knowing whether something makes sense as a per-instance
member or not."

hi Peter,

I believe that the "this command" should be used allways,
i.e. to use
this.member1
this.property1
etc
because doing so would solve any
per-instance member issues, am I correct ?

I suppose that depends on what you mean by "per-instance member issues".
But taken literally, I don't think what you wrote is relevant here.

In most cases, the "this" keyword is not necessary. When you need to
explicitly reference the instance itself from within an instance method,
such as passing the reference to something else, or when you need to
distinguish a field member from a method argument of the same name, then
you'd need the "this" keyword. But it's not _solving_ a per-instance
member issue per se. That is, you can't get yourself out of a
per-instance member design issue by throwing the "this" keywoard at it.
All that "this" does is help the _implementation_ work correctly. If the
design is flawed, it's still flawed even if you use "this".

Pete

[=?Utf-8?B?Umljaw==?=]

Thanks to you all; I got it to work using your suggestions.
"Peter Duniho" wrote:

On Wed, 29 Oct 2008 03:26:15 -0700, xcal <[e-mail]:

" It's about knowing whether something makes sense as a per-instance
member or not."

hi Peter,

I believe that the "this command" should be used allways,
i.e. to use
this.member1
this.property1
etc
because doing so would solve any
per-instance member issues, am I correct ?

I suppose that depends on what you mean by "per-instance member issues".
But taken literally, I don't think what you wrote is relevant here.

In most cases, the "this" keyword is not necessary. When you need to
explicitly reference the instance itself from within an instance method,
such as passing the reference to something else, or when you need to
distinguish a field member from a method argument of the same name, then
you'd need the "this" keyword. But it's not _solving_ a per-instance
member issue per se. That is, you can't get yourself out of a
per-instance member design issue by throwing the "this" keywoard at it.
All that "this" does is help the _implementation_ work correctly. If the
design is flawed, it's still flawed even if you use "this".

Pete