[Laszlo-dev] About moving nodes...

[Raju Bitter]

There's a typo in the code: It's AS2 instead of AS3 in this line, of  
course...
   Debug.warn("Moving display objects from one movieclip to another  
not supported in AS2");
On Oct 17, 2009, at 9:10 PM, Raju Bitter wrote:

> I remember that this is a limitation of an the SWF runtime until AS2/ 
> SWF8. Starting with AS3/SWF9 the behavior of managing visible  
> objects was modified:
>
> http://my.safaribooksonline.com/0596526954/ID-d2450e71-Introduction529380
>> Anytime a MovieClip was created (in AS2), it was automatically  
>> added into the visual hierarchy and consequently drawn by the  
>> renderer. MovieClips weren't able to move to different places  
>> within the hierarchy; instead, they first had to be destroyed and  
>> then recreated before they could be positioned elsewhere in the  
>> display.
>>
>> The new renderer (AS3/SWF9) is still hierarchical, but not as  
>> rigid, and aims to simplify and optimize the rendering process. The  
>> new rendering model centers on the display list concept and focuses  
>> on the classes available in the flash.display package. The display  
>> list is a hierarchy that contains all visible objects in the .swf  
>> movie. Any object not on the display list is not drawn by the  
>> renderer.
>
> That means, you can remove the object from a display list and add it  
> to a new display list. Here's a code example:
> <canvas width="100%" height="800">
>
>  <view id="containerA" y="100" width="200" height="200"  
> bgcolor="blue">
>    <view id="targetObj" width="150" height="150" bgcolor="yellow">
>      <method name="whereAmI">
>        Debug.write("Parent for targetObj view: " + this.parent);
>        var s = this.getDisplayObject();
>        Debug.write(s);
>        Debug.write("Owner for targetObj view: ", s.parent.owner);
>      </method>
>      <button text="Click me!" onclick="parent.whereAmI()" />
>    </view>
>  </view>
>
>  <view id="containerB" x="400" y="100" width="200" height="200"  
> bgcolor="green">
>
>  </view>
>
>  <button text="move yellow view" onclick="moveView()">
>    <method name="moveView">
>      if ($as3) {
>        #passthrough {
>        Debug.write(containerA.getDisplayObject());
>        var spriteA = containerA.getDisplayObject();
>        spriteA.removeChild(targetObj.getDisplayObject());
>        var spriteB = containerB.getDisplayObject();
>        spriteB.addChild(targetObj.getDisplayObject());
>        }#
>      } else if ($as2) {
>        Debug.warn("Moving display objects from one movieclip to  
> another not supported in AS3");
>      }
>    </method>
>  </button>
>
> </canvas>
>
> Run this in SWF: you can move the yellow view from the blue to the  
> green box. #containerA is still listed as parent, even if the yellow  
> view has been attached to #containerB, but the owner reference  
> changes.
>
> @Henry: Do you have any idea what impact such an action of would  
> have on the OL view system?
>
> - Raju
>
> On Oct 17, 2009, at 7:18 PM, P T Withington wrote:
>
>> There is a `placement` attribute, and a `determinePlacement` method  
>> that can be overridden by a class, but both of these expect the  
>> final placement of a node to be determined at construct time.  I  
>> don't know if this restriction is inherent to LzNode, or was a  
>> restriction due to some ancient runtime (e.g., swf5).  It might be  
>> possible to make placement dynamic.  Clearly any parent/child  
>> dependencies would have to be tracked and adjusted as part of this.
>>
>> <state> is sort of a half-step to this, in that it can dynamically  
>> remove and add child views, but state does _not_ guarantee the  
>> child view's state information is preserved.  In effect a state  
>> destroys and re-creates the child views it controls each time.
>>
>> You can modulate the `visible` attribute of a view to hide/reveal  
>> it and all its children.  Modulating the visibility _does_ preserve  
>> the hidden views state.
>>
>> I'd be interested in seeing an example of an application where  
>> views need to move.
>>
>> On 2009-10-16, at 20:39, Rami Ojares / AMG Oy wrote:
>>
>>> Hi,
>>>
>>> Would it even be theoretically possible to make parent attribute  
>>> of node read/write.
>>> Now moving nodes around means destroying old ones and creating new  
>>> ones under new parent.
>>> This becomes a nightmare when the nodes have all kinds of  
>>> connections to other nodes.
>>>
>>> I know this is a BIG issue but I wondered if this would be even  
>>> theoretically possible and what it would require.
>>>
>>> Now that I do it manually I will have to maintain two way links  
>>> between dependencies.
>>>
>>> Example:
>>> - A depends on B (a is listening to events from B)
>>>
>>> If I move B I have to know who is listening so I can update the  
>>> delegates to listen to events from the new B node
>>> If I could move B without destroying it and creating a new one,  
>>> the delegates would not need updating.
>>>
>>> - rami
>>>
>>
>