My point is not modal specifically. The issue is that moving components around as well as states which might change the parent of a component.
Recreating components have two problems: 1. There’s the overhead and garbage collection involved. 2. You lose state. The problem with UIBase is that all the beads are added (and re-added) there. I don’t know how to work around that issue. > On Nov 13, 2018, at 10:15 AM, Alex Harui <[email protected]> wrote: > > I'm not sure I understand why "modal" matters. It sounds like you have some > display object you want to parent and unparent and then re-parent. For sure, > lots of code worked that way in Flex but does it have to work that way in > Royale? Why not just toss the instance when you unparent it and create a new > one when you next need it? Or make the modal invisible and visible again? > > If there is a good reason I would not want a flag in every instance of UIBase > only for the few top-level widgets that are going to be re-parented. We > might refactor addedToParent to call a method that sets up the "first time > only" stuff. Then the classes that are likely to be reparented can have a > flag and override of the "first-time-only" method. > > I thought every bead that comes from a ValuesManager lookup is supposed to > check the strand first. > > My 2 cents, > -Alex > > On 11/13/18, 12:05 AM, "Harbs" <[email protected]> wrote: > > I ran into a problem today trying to create a “modal” bead. > > Every time a component is added or moved from one parent to another, > addedToParent() is called which adds all the declared beads as well as looks > up beads from the ValuesManager. Besides having extra overhead, this results > in duplicate beads if declared via MXML. > > The simplest way to fix this would be to have a private flag which is set > the first time a component is added to a parent and if the flag is set, the > bead-setup code would not be run. This is a bit of “just in case” code, but > I’ not sure how else to resolve this. > > Thoughts? > Harbs >
