ByVal TreeView Modifies Original?

C

casManG

I am working on a small project that uses the treeview control in .net
2003. I have a tree view that I am sending to a sub in order to
iterate through the nodes.

Public Sub test (ByVal inTreeView as Tree View)

But, the thing I want to do with the inTreeView requires me to expand
all the nodes before I iterate. The problem is that when the sub is
complete, the original tree view on my form ends up with all of the
nodes expanded I had hoped that sending it to my sub "ByVal" would
make a copy that I could mess around with without effecting the
original. I also tried creating a new treeview and assigning the
inTreeView to it, then doing my stuff:

dim TestTree as new TreeView
TestTree = inTreeView

but no matter what the source treeview always gets expanded when I do
an expandall TestTree.ExpandAll()

Can anyone tell me how to get a duplicate of a treeview in a way that
I can expandall and not effect the source object?

Thanks
cas
 
B

Branco Medeiros

cas wrote:
<backposted/>

I suppose you know that you have value and reference types in VB (or,
actually, in .Net). A reference type, which the TreeView happens to
be, must allocate its data in a special memory area called "heap", and
live there until it's reclaimed by a memory management code called
garbage collector.

Well, reference types are represented by *pointers*, that is, a value
that *references* their address in the heap.

When you declare a variable of a reference type, such as a treeview,
you're declaring a placeholder for that "pointer", just that. When
that variable is assigned a value, it "points to" the address of the
actual data that lives in the heap.

The thing with reference types is that you can pass their pointers
around, and each variable will be pointing to (or referencing) the
same location in memory, the same object.

Then, when you pass a variable of a reference type ByVal, you create a
copy *of the pointer* and assigns to a temporary variable. What this
does is to protect your original *variable* (not the original object,
which lives far away, in the heap) from being modified. This prevents,
for instance, the called code from assigning, say, Nothing to your
variable, making it completely unusable in its original context. Or
from assignin' it the pointer to a completely different object, which
might create a complete confusion in your code (if it wasn't what you
expected).

The thing to be aware of is, as you could see, even though a variable
of a reference type passed ByVal is protected, the object it points to
is not. Anything in the object can be modified by the called code,
because just a copy of the reference was passed, not a copy of the
object...

Notice that when you create a variable with "New", as you did with
your TestTree in your attempt to create a *damn new tree view*, you
*are* creating a new object in the heap. And the address of that new
object is being assigned to your variable. But then, when you assign
the value of your original treeview to TestTree, guess what
happened... the pointer it had to the new treeview was replaced by the
pointer to the old one, just nullifying your efforts (and leaving an
unreferenced object in the heap, ready to be collected by the garbage
collector in its next scan).

What you'd want is some sort of clone method, which I don't suppose
the treeview exposes...

Sorry for the bad news.

Regards,

Branco.
 
C

casManG

cas wrote:

<backposted/>

I suppose you know that you have value and reference types in VB (or,
actually, in .Net). A reference type, which the TreeView happens to
be, must allocate its data in a special memory area called "heap", and
live there until it's reclaimed by a memory management code called
garbage collector.

Well, reference types are represented by *pointers*, that is, a value
that *references* their address in the heap.

When you declare a variable of a reference type, such as a treeview,
you're declaring a placeholder for that "pointer", just that. When
that variable is assigned a value, it "points to" the address of the
actual data that lives in the heap.

The thing with reference types is that you can pass their pointers
around, and each variable will be pointing to (or referencing) the
same location in memory, the same object.

Then, when you pass a variable of a reference type ByVal, you create a
copy *of the pointer* and assigns to a temporary variable. What this
does is to protect your original *variable* (not the original object,
which lives far away, in the heap) from being modified. This prevents,
for instance, the called code from assigning, say, Nothing to your
variable, making it completely unusable in its original context. Or
from assignin' it the pointer to a completely different object, which
might create a complete confusion in your code (if it wasn't what you
expected).

The thing to be aware of is, as you could see, even though a variable
of a reference type passed ByVal is protected, the object it points to
is not. Anything in the object can be modified by the called code,
because just a copy of the reference was passed, not a copy of the
object...

Notice that when you create a variable with "New", as you did with
your TestTree in your attempt to create a *damn new tree view*, you
*are* creating a new object in the heap. And the address of that new
object is being assigned to your variable. But then, when you assign
the value of your original treeview to TestTree, guess what
happened... the pointer it had to the new treeview was replaced by the
pointer to the old one, just nullifying your efforts (and leaving an
unreferenced object in the heap, ready to be collected by the garbage
collector in its next scan).

What you'd want is some sort of clone method, which I don't suppose
the treeview exposes...

Sorry for the bad news.

Regards,

Branco.

Ok, thank you for your reply :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top