«

I have a dictionary object, then I create a new dictionary object and sets
it equal to my original, then I pass the new dictionary object to a function
that changes some of my values - but then my original dictionary also gets
changed and that was not the intention, can someone explain to me why it
behaves that way and how do I avoid it, så I van have different dictionary
objects?

Thanks Betina

Betina Andersen wrote:

> I have a dictionary object, then I create a new dictionary object and sets
> it equal to my original, then I pass the new dictionary object to a function
> that changes some of my values - but then my original dictionary also gets
> changed and that was not the intention, can someone explain to me why it
> behaves that way and how do I avoid it, så I van have different dictionary
> objects?
>

Looks like it's because the argument is passed to the function ByRef,
meaning that instead of passing 'the thing' into the function you just
get a reference to 'the thing'. So any changes you make to 'the thing'
will be reflected in the original.

I haven't used ASP for a long time, but you need to change the argument
to be ByVal, which means you get a *copy* of 'the thing', like in the
following code:

<%
function monkey(byval thing)
monkey = thing & "<br/>"
thing = thing + 1
end function

dim a
a = 1

response.write monkey(a)
response.write a
%>

You should see two 1s if it's worked as expected. Take the 'byval'
away and you get 1 and 2, because the argument is Byref again and the
function was able to monkey around with the original variable.

"Betina Andersen" <> wrote in message
news:...
> I have a dictionary object, then I create a new dictionary object and sets
> it equal to my original, then I pass the new dictionary object to a
function
> that changes some of my values - but then my original dictionary also gets
> changed and that was not the intention, can someone explain to me why it
> behaves that way and how do I avoid it, så I van have different dictionary
> objects?

My very old copy of MSDN says...

"Generally, when you use Set to assign an object reference to a variable, no
copy of the object is created for that variable. Instead, a reference to the
object is created. More than one object variable can refer to the same
object. Because these variables are references to (rather than copies of)
the object, any change in the object is reflected in all variables that
refer to it."

I would guess that the following occurs...

dim x
dim z

set x = CreateObject("Scripting.Dictionary")
'x contains (for instance) the number 536474
'which is a memory address that points to the dictionary object

set z = CreateObject("Scripting.Dictionary")
'z contains a pointer to a different object e.g. the memory address 73462

set z = x
'z now contains 536474, and so points to the original object - same as x


I think you need something like this...

set z = copydict(x)

function copydict(x)
dim j, k, i, z

set z = CreateObject("Scripting.Dictionary")

k = x.Keys
i = x.Items
for j = 0 to x.Count - 1
z.Add k(j), i(j)
next
set copydict = z
end function


--
roger

roger wrote:

> "Generally, when you use Set to assign an object reference to a variable, no
> copy of the object is created for that variable. Instead, a reference to the
> object is created. More than one object variable can refer to the same
> object. Because these variables are references to (rather than copies of)
> the object, any change in the object is reflected in all variables that
> refer to it."
>

I guess that's why these things have .clone() methods (see ADO
recordset). Except in this case, where it would be useful.

"Bobbo" <> wrote in message
news: oups.com...
>
> roger wrote:
>
> > "Generally, when you use Set to assign an object reference to a
variable, no
> > copy of the object is created for that variable. Instead, a reference to
the
> > object is created. More than one object variable can refer to the same
> > object. Because these variables are references to (rather than copies
of)
> > the object, any change in the object is reflected in all variables that
> > refer to it."
> >
>
> I guess that's why these things have .clone() methods (see ADO
> recordset). Except in this case, where it would be useful.
>

I've not seen any objects in common use that have clone method of the type
desired by the OP.

The clone method of a recordset allow a new filter and seek position to be
created independant of the orginal recordset object. However the underlying
data remains the same if you change the data in one the changes are visible
in the other.