By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,366 Members | 1,366 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,366 IT Pros & Developers. It's quick & easy.

Setting a referenced object to null

P: n/a
Joe
I might be overworked so please excuse this stupid question...

Say I do the following:

DataTable table = new DataTable();

myDataAdaptor.Fill(table);

dataGrid1.DataSource = table;

table = null;

Why does dataGrid1.DataSource still point to a table?

How can I set an object to null and have all references to that object now
be null?

Thanks,
Joe
Feb 20 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Joe,
dataGrid1.DataSource = table;

table = null;

Why does dataGrid1.DataSource still point to a table?
Because DataSource has its own copy of the reference to the table.
How can I set an object to null and have all references to that object now
be null?


You can't. I frankly non of the languages that I know can do that unless the
classes are specially designed to use some kind of indirect reference where
they reference an object that holds the real reference. In this case
modifying the reference in this "proxy" class will cut off all the
references to the real object.
--

Stoitcho Goutsev (100)
Feb 20 '06 #2

P: n/a
"Joe" <jb*******@noemail.noemail> a écrit dans le message de news:
Oz**************@TK2MSFTNGP12.phx.gbl...

|I might be overworked so please excuse this stupid question...
|
| Say I do the following:
|
| DataTable table = new DataTable();
|
| myDataAdaptor.Fill(table);
|
| dataGrid1.DataSource = table;
|
| table = null;
|
| Why does dataGrid1.DataSource still point to a table?
|
| How can I set an object to null and have all references to that object now
| be null?

You can't. You can only set references to objects to null.

If you know C tthen you would remember that object references hold the
addresses of objects and you would have to dereference that pointer to get
at the object. You could "delete" the object and then the pointer would be
invalid and would have to be nulled to avoid AVs.

In C#, all objects are garbage collected, you can't "delete" them. When the
last reference to a given object falls out of scope, the object is liable to
collection. You can certainly null as many references as you can find, but
the object will remain alive as long as *any* reference still holds that
object.

In your example, the DataGris's DataSource is holding a reference to the
table, so even though you null the original reference, 'table', the object
that 'table' was pointing to is kept alive by the DataSource property.

Why would you want to null a property to which you have only just assigned a
valid object ?

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 20 '06 #3

P: n/a
Joe
Hi,

Your answer is what I thought. I just wanted to make sure I wasn't loosing
my mind...

BTW - The example I wrote was just to show a really small and quick example
of what I meant. I don't think anyone would ever do as my example displayed.

-Joe

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:uC*************@TK2MSFTNGP12.phx.gbl...
"Joe" <jb*******@noemail.noemail> a écrit dans le message de news:
Oz**************@TK2MSFTNGP12.phx.gbl...

|I might be overworked so please excuse this stupid question...
|
| Say I do the following:
|
| DataTable table = new DataTable();
|
| myDataAdaptor.Fill(table);
|
| dataGrid1.DataSource = table;
|
| table = null;
|
| Why does dataGrid1.DataSource still point to a table?
|
| How can I set an object to null and have all references to that object
now
| be null?

You can't. You can only set references to objects to null.

If you know C tthen you would remember that object references hold the
addresses of objects and you would have to dereference that pointer to get
at the object. You could "delete" the object and then the pointer would be
invalid and would have to be nulled to avoid AVs.

In C#, all objects are garbage collected, you can't "delete" them. When
the
last reference to a given object falls out of scope, the object is liable
to
collection. You can certainly null as many references as you can find, but
the object will remain alive as long as *any* reference still holds that
object.

In your example, the DataGris's DataSource is holding a reference to the
table, so even though you null the original reference, 'table', the object
that 'table' was pointing to is kept alive by the DataSource property.

Why would you want to null a property to which you have only just assigned
a
valid object ?

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

Feb 20 '06 #4

P: n/a
Joe,

The statement:

DataTable table = new DataTable();

creates a new DataTable object in the heap, and stores a reference to this
object in the variable 'table'.

The statement:

dataGrid1.DataSource = table;

COPIES the reference stored in the 'table' var to dataGrid1.DataSource.

The statement:

table = null;

assigns null to 'table', so 'table' does not point anymore to the
dynamically created object; but dataGrid1.DataSource still points at it.

There is no direct way to know from what different places an object might be
referenced. The CLR keeps track of that, and will automatically reclaim the
memory used by the object when no references points at it.

Regards - Octavio
"Joe" <jb*******@noemail.noemail> escribió en el mensaje
news:Oz**************@TK2MSFTNGP12.phx.gbl...
I might be overworked so please excuse this stupid question...

Say I do the following:

DataTable table = new DataTable();

myDataAdaptor.Fill(table);

dataGrid1.DataSource = table;

table = null;

Why does dataGrid1.DataSource still point to a table?

How can I set an object to null and have all references to that object now
be null?

Thanks,
Joe

Feb 20 '06 #5

P: n/a
"Joe" <jb*******@noemail.noemail> a écrit dans le message de news:
OT**************@TK2MSFTNGP14.phx.gbl...

| BTW - The example I wrote was just to show a really small and quick
example
| of what I meant. I don't think anyone would ever do as my example
displayed.

Just checking :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 20 '06 #6

P: n/a
Joe <jb*******@noemail.noemail> wrote:
I might be overworked so please excuse this stupid question...

Say I do the following:

DataTable table = new DataTable();

myDataAdaptor.Fill(table);

dataGrid1.DataSource = table;

table = null;

Why does dataGrid1.DataSource still point to a table?

How can I set an object to null and have all references to that object now
be null?


The important thing is that you're not setting an object to null.
You're not even setting a reference to null, really.

You're changing the variable's value to null. That doesn't affect
anything other than the value of that variable - so the fact that
dataGrid1.DataSource happened to have a reference value which was the
same as the value of table is irrelevant.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 20 '06 #7

P: n/a
Question:

If I create an instance of a value type object (int for example), that
value is stored directly on the stack is it not? And my variable
points directly at the location in the stack where the integer value is
stored? Is that correct?

If I create an instance of a reference type, the object itself is
created on the heap correct? And the variable holds the address of
that object on the heap. Where is the value of the variable stored?
Is it stored on the heap as well? Or is it stored on the stack?

Feb 21 '06 #8

P: n/a
Chris Dunaway <du******@gmail.com> wrote:
Question:

If I create an instance of a value type object (int for example), that
value is stored directly on the stack is it not?
Not always - it depends on the type of the variable.
And my variable
points directly at the location in the stack where the integer value is
stored? Is that correct?
If it's a local variable, yes.
If I create an instance of a reference type, the object itself is
created on the heap correct?
Yes.
And the variable holds the address of that object on the heap.
Well, that's the value of the variable.
Where is the value of the variable stored?
Is it stored on the heap as well? Or is it stored on the stack?


It depends on whether the variable is a local variable, an instance
variable etc. See http://www.pobox.com/~skeet/csharp/memory.html

Where a variable's value is stored does *not* depend on the type of the
variable (in terms of whether it's a reference type or a value type).
It only depends on what kind of variable it is (local, instance, static
etc).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 21 '06 #9

P: n/a
You can force the garbageCollector to free up the memory.
But you HAVE to remove ANY refenrence to the table object. If the table
object has to references it is eligble for GarbageCollector.

GarbageCollector is a complicated matter, but you SELDOM need to call it
manually. It is tweaked at the best to release memory when needed.

Your answere is that it is doable, but the time and effort to do it is not
worth it.
"Joe" <jb*******@noemail.noemail> wrote in message
news:Oz**************@TK2MSFTNGP12.phx.gbl...
I might be overworked so please excuse this stupid question...

Say I do the following:

DataTable table = new DataTable();

myDataAdaptor.Fill(table);

dataGrid1.DataSource = table;

table = null;

Why does dataGrid1.DataSource still point to a table?

How can I set an object to null and have all references to that object now
be null?

Thanks,
Joe

Feb 21 '06 #10

P: n/a
I have been struggling with this for weeks now. The example the
original person asked isn't QUITE what I'm looking for, but I have a
more likely example. I have run into this a number of times now.

1) Add a dataSet to a form (windows or web) - call it dataSet11.
2) Add a databinding for 10 controls on that form to use the dataset.
3) Fill the dataset (using a SQLDataAdapter for example)

On a windows form at this point, the controls will show all of the data
in that dataset. Using the reference dataSet11 you can manipulate that
dataset. Add rows, remove rows, modify the underlying data etc.
Everything works great.

However, what if at this point you create a filtered view of that data.
So, you add the following.

DataSet dsTemp = dataSet11.Clone();

Now - you delete 80% of the records, and "filter" the data based on any
random criteria.

Now, you want to use that new dataset (dsTemp) on your form. As
expected, if I put:

dataSet11 = dsTemp;

Because it will just point the reference dataset11 to point to the new
dataset.

The problem is that the 10 controls on the form are still pointing /
referencing the original dataset.

What I REALLY want to be able to do (and really feel like I SHOULD be
able to do) is something like the following.

dataSet11* = &dsTemp;

Now - the memory on the heap that dataSet11 is pointing to is adjusted
to point to the new dataset (dsTemp). Automtically (with a call like
the above), ALL of the referneces ("pointer") would automatically be
pointing at the new/filtered DataSet.

Without this (or something like this), you'd have to write a bunch of
code (and it seems like it'd be REALLY inefficient) and iterate over
every control on the form and re-bind it to the new dataset (dsTeemp).
Right? That seems silly to me...

Thoughts?

EJ
ubrinc.biz

*** Sent via Developersdex http://www.developersdex.com ***
Mar 8 '06 #11

P: n/a
The first problem here is that you're thinking and talking like a user. That
is, you're being very fuzzy about what exactly your business requirement is,
how you're attempting to achieve the business requirement, and what you're
using to attempt your solution with.

"The controls" is an extremely non-specific description. Even a Form is a
Control. I'm going to go out on a limb here and make an educated guess that
you're apparently data-binding some sort of interface controls to a DataSet.
Furthermore, I can probably safely assume that these are for the most part
some sort of grid controls, but I can't be sure at all. Still, it doesn't
matter that much. The point is that they are bound to a DataSet.

Moving ahead, these Controls are not directly bound to the DataSet.
Depending upon what version of the .Net Framework you're using, you may be
binding the Controls to a set of BindingSource instances, or perhaps to a
set of DataViews, or some other binding medium. They are *not* bound
directly to the DataSet, as a DataSet is just a logical container for a set
of DataTables. But you haven't been specific about that either. And the
devil is in the details.

Now, you're talking about manipulating the DataSet directly, for some
reason. The DataSet is usually a conduit to an underlying Data Source such
as a database, although you didn't say (you did mention a DataAdapter, so
I'll suppose that this is true).

Now, you start off talking about manipulating the DataSet. Somehow. You
aren't specific about that either. You may be doing it entirely
programmatically, or by some combination of the interaction of the user with
the Controls, combined with some manipulation of the DataAdapter(s). Again,
you didn't say. In fact, you didn't mention whether or not you're actually
changing the underlying Data Source or not. A DataSet is a disconnected set
of data that is fetched (copied) from a database (usually). In order to
update the underlying Data Source, you have to use your DataAdapters. How
and when is up to you, but you haven't mentioned anything about that.

Next, you talk about creating a filtered view of the data by cloning the
DataSet, and apparently deleting records from various DataTables in the
cloned DataSet according to some arbitrary "random criteria" (via what
mechanism, you don't say).

At this point, I'm really scratching my head. I can't imagine any business
requirement that would entail deleting records at random. Usually (almost
always) there is some logic to the manipulation, and that logic determines
what records are deleted and what records are not, as well as how. In fact,
you shouldn't be talking about deleting records from the DataSet unless you
plan to delete them in the database as well.

So, at this point, you've stepped off the beaten path and entered the realm
in which you must begin to depend upon your own programming skills to
manipulate the data. In fact, you stepped off the beaten path when you
cloned the first DataSet to filter it. Remember, that DataSet is a proxy for
your underlying Data Store. It is an ambassador, if you will. But now you've
cloned the ambassador, and are working with the clone, who may or may not
(most probably *not*) have any relationship whatsoever with the underlying
Data Store.

Next, you assign the variable you're using ("dataSet11") to the second
DataSet. Note what I've just said here: You didn't assign the *DataSet* to
the second DataSet. Of course, you could not. You assigned the variable, the
reference. Of course the 10 Controls on the form are still referencing the
first DataSet. You haven't done anything *to* the first DataSet. A variable
is simply a handle that is used to access something. All you did was make
the variable reference something else. In essence, where it *was* pointing
to the first DataSet, it is *now* pointing to the second.

When you say that what you want is something like:
dataSet11* = &dsTemp;
- in fact, that is exactly what you got (in a managed sort of way). A
reference type is a managed pointer to an object. So, when you assigned that
"pointer" to the second DataSet, you simply pointed it away from the first
DataSet to point to the second.

But that isn't really what you want to do at all. You've gone way off track,
starting all the way back where I mentioned earlier. So, what we really need
to do is go all the way back to your requirements, *understand how these
tools are designed to be used*, and use them *as they were designed* to
achieve those requirements. Now, what would those requirements be?

I can (again) make some guesses. Let's see how close I can get. You have a
database. You want to create an interface to that database, using ADO.Net
tools and a Windows Forms application. You have a DataSet, which I presume,
is a proxy to the database itself. It is important to note here that the
DataSet is empty until you fill it. What you fill it with is up to you. But
let's assume that for some reason you want to start out with the contents of
10 (?) tables. So, you need to bind those tables to the 10 Controls you
mentioned. But apparently you don't want to display all of the data. So, you
need to filter what is seen and what is not seen. How this is done depends
upon the filter condition you specify. "random criteria" is achievable, but
will require quite a bit of work. Do you have a more specific requirement?
Perhaps, for instance, only 100 records at a time? Ordered in what way? Not
ordered? Filtered by what specific criteria?

Once we determine the answers to these questions, we can determine, based
upon the various capabilities and aspects of the tools, how best to achieve
the goal. But remember, the DataSet you start out with is your connection to
the DataBase. You don't have to look at all of it at once. You don't even
have to fill it all at once. But what you do is going to be based on your
business requirements.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

"Billy Bob" <no****@devdex.com> wrote in message
news:Od**************@TK2MSFTNGP09.phx.gbl...I have been struggling with this for weeks now. The example the
original person asked isn't QUITE what I'm looking for, but I have a
more likely example. I have run into this a number of times now.

1) Add a dataSet to a form (windows or web) - call it dataSet11.
2) Add a databinding for 10 controls on that form to use the dataset.
3) Fill the dataset (using a SQLDataAdapter for example)

On a windows form at this point, the controls will show all of the data
in that dataset. Using the reference dataSet11 you can manipulate that
dataset. Add rows, remove rows, modify the underlying data etc.
Everything works great.

However, what if at this point you create a filtered view of that data.
So, you add the following.

DataSet dsTemp = dataSet11.Clone();

Now - you delete 80% of the records, and "filter" the data based on any
random criteria.

Now, you want to use that new dataset (dsTemp) on your form. As
expected, if I put:

dataSet11 = dsTemp;

Because it will just point the reference dataset11 to point to the new
dataset.

The problem is that the 10 controls on the form are still pointing /
referencing the original dataset.

What I REALLY want to be able to do (and really feel like I SHOULD be
able to do) is something like the following.

dataSet11* = &dsTemp;

Now - the memory on the heap that dataSet11 is pointing to is adjusted
to point to the new dataset (dsTemp). Automtically (with a call like
the above), ALL of the referneces ("pointer") would automatically be
pointing at the new/filtered DataSet.

Without this (or something like this), you'd have to write a bunch of
code (and it seems like it'd be REALLY inefficient) and iterate over
every control on the form and re-bind it to the new dataset (dsTeemp).
Right? That seems silly to me...

Thoughts?

EJ
ubrinc.biz

*** Sent via Developersdex http://www.developersdex.com ***

Mar 9 '06 #12

P: n/a

"Billy Bob" <no****@devdex.com> wrote in message
news:Od**************@TK2MSFTNGP09.phx.gbl...
I have been struggling with this for weeks now. The example the
original person asked isn't QUITE what I'm looking for, but I have a
more likely example. I have run into this a number of times now.

1) Add a dataSet to a form (windows or web) - call it dataSet11.
2) Add a databinding for 10 controls on that form to use the dataset.
3) Fill the dataset (using a SQLDataAdapter for example)

On a windows form at this point, the controls will show all of the data
in that dataset. Using the reference dataSet11 you can manipulate that
dataset. Add rows, remove rows, modify the underlying data etc.
Everything works great.

However, what if at this point you create a filtered view of that data.
So, you add the following.

DataSet dsTemp = dataSet11.Clone();

Now - you delete 80% of the records, and "filter" the data based on any
random criteria.

Now, you want to use that new dataset (dsTemp) on your form. As
expected, if I put:

dataSet11 = dsTemp;


Have we covered using Clear() and Merge()?

It occurs to me that it should be possible to write a decorator for the
dataset that you bind to instead of the real dataset - this would then have
a read/write DataSource property that it would in turn bind to and forward
events from. The only problem is integrating it with the designer.
Mar 9 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.