loadBeadFromValuesManager does check first, but that all does have overhead. How much, I’m not sure, but I can see that an app which might do a lot of moving around elements can take a hit.
> On Nov 13, 2018, at 11:17 AM, Alex Harui <[email protected]> wrote: > > I see that beads specified in the beads array could get added each time, but > I thought that loadBeadFromValuesManager checked the strand first. If not, > maybe it should. > > In Flex, there was enough overhead in getting a dialog up that it was > recommended to create something once and re-parent it. And some folks had to > add code to "reset" dialogs that were re-used. I'm wondering if we have the > same issues in Royale. Also, in theory, in MVC, state should be stored in a > model separate from the View/Dialog that presents that state. > > That said, you are correct that with states, pretty much anything can be > re-parented, so I adding a flag is ok for now, although I have been thinking > about pulling all states-related overhead out into a bead. > > My 2 cents, > -Alex > > On 11/13/18, 12:54 AM, "Harbs" <[email protected]> wrote: > > 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 >> > > >
