Datasets? Properties? Values?

[Charles A. Lackman]

Hello,

I have been working with an application that sends a dataset to other forms
that are called from individual DLL's.

I have noticed that, a dataset that is passed to another form, when changed,
changes the dataset in all of the forms.
But, if you send a string to the other forms, that the value is independant
on each form.. I.E.

Called Form from a DLL:

Dim ADataset As New DataSet()
Dim FormNumber As String

Public Property RefDataset() As DataSet
Get
Return RefDataset
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property

Public Property WhatForm() As String
Get
Return WhatForm
End Get
Set(ByVal Value As String)
FormNumber = Value
End Set
End Property

If I change the data inside the 'ADataset' the Main App's and the called
form's datasets change together (all of them) which is good and fine for
what I need it for.
But if I change the FormNumber only the called form's FormNumber Changes and
not all of them.
Is this normal? Does this have something to do with how datasets are
created that makes it work for a Dataset and Not other values?

Any suggestions will be greatly appreciated,

Thank,
Chuck

[Joey Callisay]

Although string is a reference type, .NET has already included handling on
it so its function will be that of a value type.

Passing a reference type (like a dataset) by value is just passing a pointer
to a particular object in memory. You cannot change the object dataset it
is pointing to yet you can change its contents. In your case, when the
contents are changed in the dataset, and it was being passed by value, the
changes will be committed to the dataset object in memory.

For the case of the string, each project will have their own copies of the
string since it behaves like a value type. Btw, does VB.NET still support
the old function name value?

Public Property RefDataset() As DataSet
Get
Return RefDataset
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property

The new way for the get property should return the private variable

Public Property RefDataset() As DataSet
Get
Return ADataset ***
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property
"Charles A. Lackman" <Ch*****@CreateItSoftware.net> wrote in message
news:em**************@TK2MSFTNGP09.phx.gbl...

Hello,

I have been working with an application that sends a dataset to other forms that are called from individual DLL's.

I have noticed that, a dataset that is passed to another form, when changed, changes the dataset in all of the forms.
But, if you send a string to the other forms, that the value is independant on each form.. I.E.

Called Form from a DLL:

Dim ADataset As New DataSet()
Dim FormNumber As String

Public Property RefDataset() As DataSet
Get
Return RefDataset
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property

Public Property WhatForm() As String
Get
Return WhatForm
End Get
Set(ByVal Value As String)
FormNumber = Value
End Set
End Property

If I change the data inside the 'ADataset' the Main App's and the called
form's datasets change together (all of them) which is good and fine for
what I need it for.
But if I change the FormNumber only the called form's FormNumber Changes and not all of them.
Is this normal? Does this have something to do with how datasets are
created that makes it work for a Dataset and Not other values?

Any suggestions will be greatly appreciated,

Thank,
Chuck

[Joey Callisay]

For the case of the string, if you want it to have a global effect, pass it
by reference
"Joey Callisay" <hc******@codex-systems.com> wrote in message
news:OJ**************@TK2MSFTNGP10.phx.gbl...

Although string is a reference type, .NET has already included handling on
it so its function will be that of a value type.

Passing a reference type (like a dataset) by value is just passing a pointer to a particular object in memory. You cannot change the object dataset it
is pointing to yet you can change its contents. In your case, when the
contents are changed in the dataset, and it was being passed by value, the
changes will be committed to the dataset object in memory.

For the case of the string, each project will have their own copies of the
string since it behaves like a value type. Btw, does VB.NET still support
the old function name value?

Public Property RefDataset() As DataSet
Get
Return RefDataset
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property

The new way for the get property should return the private variable

Public Property RefDataset() As DataSet
Get
Return ADataset ***
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property
"Charles A. Lackman" <Ch*****@CreateItSoftware.net> wrote in message
news:em**************@TK2MSFTNGP09.phx.gbl...

Hello,

I have been working with an application that sends a dataset to other

forms

that are called from individual DLL's.

I have noticed that, a dataset that is passed to another form, when

changed,

changes the dataset in all of the forms.
But, if you send a string to the other forms, that the value is

independant

on each form.. I.E.

Called Form from a DLL:

Dim ADataset As New DataSet()
Dim FormNumber As String

Public Property RefDataset() As DataSet
Get
Return RefDataset
End Get
Set(ByVal Value As DataSet)
ADataset = Value
End Set
End Property

Public Property WhatForm() As String
Get
Return WhatForm
End Get
Set(ByVal Value As String)
FormNumber = Value
End Set
End Property

If I change the data inside the 'ADataset' the Main App's and the called
form's datasets change together (all of them) which is good and fine for
what I need it for.
But if I change the FormNumber only the called form's FormNumber Changes

and

not all of them.
Is this normal? Does this have something to do with how datasets are
created that makes it work for a Dataset and Not other values?

Any suggestions will be greatly appreciated,

Thank,
Chuck

[Jon Skeet [C# MVP]]

Joey Callisay <hc******@codex-systems.com> wrote:

Although string is a reference type, .NET has already included handling on
it so its function will be that of a value type.

Not really. There's nothing special about string here. It's just an
immutable object, like any other immutable object one could design.

There *are* ways in which the CLR treats strings in a special manner,
but this isn't one of them.

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

[Jon Skeet [C# MVP]]

Charles A. Lackman <Ch*****@CreateItSoftware.net> wrote:

I have been working with an application that sends a dataset to other forms
that are called from individual DLL's.

I have noticed that, a dataset that is passed to another form, when changed,
changes the dataset in all of the forms.
But, if you send a string to the other forms, that the value is independant
on each form.. I.E.

<snip>

See http://www.pobox.com/~skeet/csharp/parameters.html

(It's C# based, but applies to VB.NET as well.)

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

[Cor Ligthert]

Jon,

Although string is a reference type, .NET has already included handling on it so its function will be that of a value type.

Not really. There's nothing special about string here. It's just an
immutable object, like any other immutable object one could design.

There *are* ways in which the CLR treats strings in a special manner,
but this isn't one of them.

What do I miss?

In my opinion is the reason is from the behaviour is that the string is
passed by its value of the pointer to its starting adres and by a change get
a new pointer.

While the dataset keeps its own pointer

Your answer is therefore not wrong, however I would not completly answer it
like you do. There is something special to the string, it is immutable and
therefore it gets evertime a new pointer.

As we disscussed before not all systems have immutable strings, so you may
call this something "special" from Net. (And let us not discuss about the
word special, maybe is not immutable at the moment "special").

Correct me when I am "completly" wrong?

Cor

[Joey Callisay]

But passing a string by value and changing the value of that string on the
receiving method will not change the original string.
Unlike passing the dataset by value, isn't it Mr. Skeet?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Joey Callisay <hc******@codex-systems.com> wrote:

Although string is a reference type, .NET has already included handling on it so its function will be that of a value type.

Not really. There's nothing special about string here. It's just an
immutable object, like any other immutable object one could design.

There *are* ways in which the CLR treats strings in a special manner,
but this isn't one of them.

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

[Jon Skeet [C# MVP]]

Cor Ligthert <no**********@planet.nl> wrote:

Not really. There's nothing special about string here. It's just an
immutable object, like any other immutable object one could design.

There *are* ways in which the CLR treats strings in a special manner,
but this isn't one of them.
What do I miss?

In my opinion is the reason is from the behaviour is that the string is
passed by its value of the pointer to its starting adres and by a change get
a new pointer.

While the dataset keeps its own pointer

No, DataSet doesn't "keep its own pointer". In both cases, they're just
reference types. You can't change the contents of a string, you can
change the contents of a DataSet. In both cases, changing the value of
a variable won't change the object though. In other words:

DataSet x = GetSomeDataSet();
x = GetSomeOtherDataSet();

doesn't change either DataSet - it just changes the value of x from a
reference to one DataSet to a reference to another DataSet.
Your answer is therefore not wrong, however I would not completly answer it
like you do. There is something special to the string, it is immutable and
therefore it gets evertime a new pointer.
But being immutable has nothing to do with the CLR. You can write your
own immutable classes which behave exactly the same way.
As we disscussed before not all systems have immutable strings, so you may
call this something "special" from Net. (And let us not discuss about the
word special, maybe is not immutable at the moment "special").

Correct me when I am "completly" wrong?

What's wrong is the impression that strings are handled differently to
other types in this respect. They're not at all. String is a reference
type which happens to be immutable. The immutability just means there
isn't any way to change the contents of the object, but that doesn't
mean the CLR handles it differently or anything like that. (Not in this
respect, anyway - interning etc is a different matter.)

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

[Jon Skeet [C# MVP]]

Joey Callisay <hc******@codex-systems.com> wrote:

But passing a string by value and changing the value of that string on the
receiving method will not change the original string.
Unlike passing the dataset by value, isn't it Mr. Skeet?

No, because you *can't* change the "value of that string". Note that
there's a big difference between changing the data within an object and
changing the value of a reference type variable. For instance, these
two methods are similar:

public void TryToChangeString (string x)
{
x = "hello";
}

public void TryToChangeDataSet (DataSet ds)
{
ds = new DataSet();
}
These two methods *aren't* similar:

public void TryToChangeString2 (string x)
{
x = "hello";
}

public void TryToChangeDataSet2 (DataSet ds)
{
ds.AcceptChanges();
}

The important thing to realise is that you never actually pass a
DataSet or a string, either by reference or by value - you pass a
*reference* to a DataSet or a string, and you can pass that reference
by reference or by value.

There's nothing special going on here - it's just the way reference
types work, and it's the same for both String and DataSet - the only
difference is that there happens to be no way of changing the contents
of a String. That's not .NET "including handling" of String in a
special way - you can write your own types which behave exactly the
same way, just by not providing any members which can change the data
in the object.

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

[Joey Callisay]

It's very interesting to have guys like you here. Good thing I posted my
views here so I got my notions corrected especially with the Immutability of
Strings (be it special or not, :p).

Thanks a lot guys.

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

Cor Ligthert <no**********@planet.nl> wrote:

Not really. There's nothing special about string here. It's just an
immutable object, like any other immutable object one could design.

There *are* ways in which the CLR treats strings in a special manner,
but this isn't one of them.

What do I miss?

In my opinion is the reason is from the behaviour is that the string is
passed by its value of the pointer to its starting adres and by a change get a new pointer.

While the dataset keeps its own pointer

No, DataSet doesn't "keep its own pointer". In both cases, they're just
reference types. You can't change the contents of a string, you can
change the contents of a DataSet. In both cases, changing the value of
a variable won't change the object though. In other words:

DataSet x = GetSomeDataSet();
x = GetSomeOtherDataSet();

doesn't change either DataSet - it just changes the value of x from a
reference to one DataSet to a reference to another DataSet.

Your answer is therefore not wrong, however I would not completly answer it like you do. There is something special to the string, it is immutable and therefore it gets evertime a new pointer.

But being immutable has nothing to do with the CLR. You can write your
own immutable classes which behave exactly the same way.

As we disscussed before not all systems have immutable strings, so you may call this something "special" from Net. (And let us not discuss about the word special, maybe is not immutable at the moment "special").

Correct me when I am "completly" wrong?

What's wrong is the impression that strings are handled differently to
other types in this respect. They're not at all. String is a reference
type which happens to be immutable. The immutability just means there
isn't any way to change the contents of the object, but that doesn't
mean the CLR handles it differently or anything like that. (Not in this
respect, anyway - interning etc is a different matter.)

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

[Charles A. Lackman]

Thank You Everyone for you help!!

Chuck

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

Charles A. Lackman <Ch*****@CreateItSoftware.net> wrote:

I have been working with an application that sends a dataset to other forms that are called from individual DLL's.

I have noticed that, a dataset that is passed to another form, when changed, changes the dataset in all of the forms.
But, if you send a string to the other forms, that the value is independant on each form.. I.E.

<snip>

See http://www.pobox.com/~skeet/csharp/parameters.html

(It's C# based, but applies to VB.NET as well.)

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