Oh, Henry was quicker. :-)
On Oct 17, 2009, at 8:11 PM, Henry Minsky wrote:
The Flash 5,6,7,and 8 runtimes couldn't reparent a movieclip, so
that was probably a big
part of the restriction on moving nodes around the hierarchy. Having
to fix constraints
is another big one though, maybe more difficult to deal with cleanly.
The Flash 10 runtime lets you reparent DisplayObjects, and so does
the DHTML DOM, so it might be worth thinking about what this
capability would be useful for in LZX.
On Sat, Oct 17, 2009 at 1:18 PM, P T Withington <p...@pobox.com> 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
--
Henry Minsky
Software Architect
hmin...@laszlosystems.com
