|
Home > Archive > Macromedia Flash Server > May 2005 > remote shared object question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
remote shared object question
|
|
| Paul Nykamp 2005-05-03, 5:45 pm |
| Hi all,
I 'm a somewhat new flashcomm developer, and yesterday I came across a
behavior with flashcomm I found unusual. I have a remote shared object with
one slot. This slot holds an array, which resides in the client swf. I load
the array into the slot using something like my_so.data.slot1 = myArray.
The unusual part comes after the first time I load the array into the shared
object slot. When I change the array on the client side, the shared object
gets updated and the onSync handler fires, even if I don't call
my_so.data.slot1 = myArray.
Can someone please confirm that this is not the expected behavior, and
whether anyone has seen this behavior before. I've attached an fla (mx not
2004) with a simplified example to demonstrate. (no server side main.asc
needed, just a folder called so_test).
Thanks in advance,
Paul Nykamp
| |
| Peldi Guilizzoni 2005-05-03, 5:45 pm |
| If you assign the array the way you are, you are in fact doing a reference
(pointer) assignment. Which means that when you change the array, the so
data will be changed too. I remember hitting this one a couple of years ago,
so weird!
The solution is to make a copy of the array and assign it instead, or loop
through it and assign each slot.
Once you know about this it can be pretty powerful though..
Peldi
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Paul Nykamp
Sent: Tuesday, May 03, 2005 9:37 AM
To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
Subject: [FlashComm] remote shared object question
Hi all,
I 'm a somewhat new flashcomm developer, and yesterday I came across a
behavior with flashcomm I found unusual. I have a remote shared object with
one slot. This slot holds an array, which resides in the client swf. I load
the array into the slot using something like my_so.data.slot1 = myArray.
The unusual part comes after the first time I load the array into the shared
object slot. When I change the array on the client side, the shared object
gets updated and the onSync handler fires, even if I don't call
my_so.data.slot1 = myArray.
Can someone please confirm that this is not the expected behavior, and
whether anyone has seen this behavior before. I've attached an fla (mx not
2004) with a simplified example to demonstrate. (no server side main.asc
needed, just a folder called so_test).
Thanks in advance,
Paul Nykamp
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Brian Lesser 2005-05-03, 5:45 pm |
| Hi Paul,
That is the expected behaviour. This may be of interest:
http://echo.ryerson.ca/arraysSharedObjects/index.html
In general storing an array in a shared object slot when the array data
changes often is not a good idea.
Yours truly,
-Brian
Paul Nykamp wrote:
>Hi all,
>
>I 'm a somewhat new flashcomm developer, and yesterday I came across a
>behavior with flashcomm I found unusual. I have a remote shared object with
>one slot. This slot holds an array, which resides in the client swf. I load
>the array into the slot using something like my_so.data.slot1 = myArray.
>
>The unusual part comes after the first time I load the array into the shared
>object slot. When I change the array on the client side, the shared object
>gets updated and the onSync handler fires, even if I don't call
>my_so.data.slot1 = myArray.
>
>Can someone please confirm that this is not the expected behavior, and
>whether anyone has seen this behavior before. I've attached an fla (mx not
>2004) with a simplified example to demonstrate. (no server side main.asc
>needed, just a folder called so_test).
>
>Thanks in advance,
>Paul Nykamp
>
>
>------------------------------------------------------------------------
>
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
--
________________________________________
______________________________
Brian Lesser
Assistant Director, Teaching and Technology Support
Computing and Communications Services
Ryerson University
350 Victoria St.
Toronto, Ontario Phone: (416) 979-5000 ext. 6835
M5B 2K3 Fax: (416) 979-5220
Office: AB48D E-mail: blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org
(Enter through LB66) Web: http://www.ryerson.ca/~blesser
________________________________________
______________________________
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Paul Nykamp 2005-05-05, 5:45 pm |
| Thanks to Brian Lesser and Peldi for answering my question, and to Brian for
the relevant link. I got around the problem by having the client call the
server and pass the array to the server then have the server update the
shared object. I also defined an onSync on the client only when I knew I
wanted to receive it. A little messy, but it works and I don't have to
rewrite a lot of stuff.
Thanks,
Paul Nykamp
> ------------------------------
>
> Message: 5
> Date: Tue, 3 May 2005 09:46:00 -0700
> From: Peldi Guilizzoni <gguilizzoni-14osZcCZf762oZ/6fjIToQ@public.gmane.org>
> Subject: RE: [FlashComm] remote shared object question
> To: FlashComm Mailing List <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Message-ID:
> < DC9D05204B1E16419D62C12561C932210104839F
-uozdpHsGBUlVE+j733TidCaUA//5aTcQ@public.gmane.org>
> Content-Type: text/plain
>
> If you assign the array the way you are, you are in fact doing a reference
> (pointer) assignment. Which means that when you change the array, the so
> data will be changed too. I remember hitting this one a couple of years
ago,
> so weird!
>
> The solution is to make a copy of the array and assign it instead, or loop
> through it and assign each slot.
>
> Once you know about this it can be pretty powerful though..
> Peldi
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Paul Nykamp
> Sent: Tuesday, May 03, 2005 9:37 AM
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> Subject: [FlashComm] remote shared object question
>
> Hi all,
>
> I 'm a somewhat new flashcomm developer, and yesterday I came across a
> behavior with flashcomm I found unusual. I have a remote shared object
with
> one slot. This slot holds an array, which resides in the client swf. I
load
> the array into the slot using something like my_so.data.slot1 = myArray.
>
> The unusual part comes after the first time I load the array into the
shared
> object slot. When I change the array on the client side, the shared object
> gets updated and the onSync handler fires, even if I don't call
> my_so.data.slot1 = myArray.
>
> Can someone please confirm that this is not the expected behavior, and
> whether anyone has seen this behavior before. I've attached an fla (mx not
> 2004) with a simplified example to demonstrate. (no server side main.asc
> needed, just a folder called so_test).
>
> Thanks in advance,
> Paul Nykamp
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 03 May 2005 12:52:01 -0400
> From: Brian Lesser <blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org>
> Subject: Re: [FlashComm] remote shared object question
> To: FlashComm Mailing List <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Message-ID: <4277AC31.2050709-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org>
> Content-Type: text/plain; format=flowed; charset=us-ascii
>
> Hi Paul,
> That is the expected behaviour. This may be of interest:
> http://echo.ryerson.ca/arraysSharedObjects/index.html
>
> In general storing an array in a shared object slot when the array data
> changes often is not a good idea.
> Yours truly,
> -Brian
>
> --
> ________________________________________
______________________________
> Brian Lesser
> Assistant Director, Teaching and Technology Support
> Computing and Communications Services
> Ryerson University
> 350 Victoria St.
> Toronto, Ontario Phone: (416) 979-5000 ext. 6835
> M5B 2K3 Fax: (416) 979-5220
> Office: AB48D E-mail: blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org
> (Enter through LB66) Web: http://www.ryerson.ca/~blesser
> ________________________________________
______________________________
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|
|
|
|
|