> Naturally, you get working output for everything, because the
> pointers created by StructCopy still point to the original structure.
Yes, but they should throw an error if they are accessing information in the
Application scope because of the CFADMIN configuration which forces strict
locking of that scope. So maybe CF doesn't properly check for strict use of
CFLOCK. I can accept that, but there's more
> You can test this by changing a value in tmpStruct AFTER you've
> created tmpPointer or tmpStructCopy; they'll both reflect the
> change, whereas tmpDuplicate won't.
True, I stuck the following code right after the closing CFSCRIPT tag and
before the closing CFLOCK:
<CFTRY>
<CFSET Application.tmpStruct['tmpSubStruct']['tmpSubSubStruct']['three']
= 'Modified' >
<CFCATCH TYPE="Any">Application.tmpStruct cleared<BR></CFCATCH>
</CFTRY>
The output for #tmpStructCopy['tmpSubStruct']['tmpSubSubStruct']['three']#
now reads "modified". Now comes the weird part...
> Also try this: at the end of your cfscript block, use StructClear to
remove
> the contents from your tmpStruct. Once you do that, you'll see that the
> pointer-based structures (tmpPointer and tmpStructCopy) will throw errors.
Ok, I stuck StructClear(Application.tmpStruct); at the end of the CFSCRIPT.
The new CFCATCH threw out "Application.tmpStruct cleared", so I know that
the StructClear() worked. But the other behavior you predicted didn't
occur... I did get an error on the pure pointer "tmpPointer is a pointer",
but I didn't get one when trying to call values out of tmpStructCopy. It
still displays values for all the struct up my "three levels deep".
I really don't know much about pointers except what I have learned and
summarized from the CF lists, but I could make two assumptions from this
behavior.
1) StructCopy() does create pointers for substructs, but if the structs it
points to (is dependant upon) is destroyed, it goes ahead and commits a copy
on them first.
or
2) I have lost my mind and am going to eat some glue now.
I'm kinda leaning towards one, but you never know, glue can be yummy.
-Cameron
--------------------
Cameron Childress
ElliptIQ Inc.
p.770.460.7277.232
f.770.460.0963
> -----Original Message-----
> From: Jeff Peters [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, November 05, 2000 5:43 PM
> To: Fusebox
> Subject: Re: StructCopy() vs Duplicate() behaviors
>
>
> On 5 Nov 00, at 14:56, Cameron Childress wrote:
>
> > I am not sure what to make of this. Either StructCopy() and Duplicate()
> > BOTH make a complete copy of all substruct info, or CF doesn't correctly
> > enforce strict usage of CFLOCK like is should be. Or maybe I'm
> > misinterpreting something....
> >
> > Comments?
>
> Your test code is similar to what I used to figure out
> Duplicate(), except for
> one thing: you don't alter the original structure before testing
> your output.
> Naturally, you get working output for everything, because the
> pointers created
> by StructCopy still point to the original structure. You can
> test this by
> changing a value in tmpStruct AFTER you've created tmpPointer or
> tmpStructCopy;
> they'll both reflect the change, whereas tmpDuplicate won't.
>
> Also try this: at the end of your cfscript block, use
> StructClear to remove
> the contents from your tmpStruct. Once you do that, you'll see that the
> pointer-based structures (tmpPointer and tmpStructCopy) will throw errors.
>
> - Jeff
>
> ==============================================================
> | Jeffrey S. Peters | "Specialization is for insects." |
> | [EMAIL PROTECTED] | - Lazarus Long |
> ==============================================================
> ------------------------------------------------------------------
> ------------
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
