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

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>

For the case of the string, if you want it to have a global effect, pass it
by reference


"Joey Callisay" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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 <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Charles A. Lackman <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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

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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Joey Callisay <(E-Mail Removed)> 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 - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

Cor Ligthert <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Joey Callisay <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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, ).

Thanks a lot guys.

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Cor Ligthert <(E-Mail Removed)> 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 - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too