Yep, updateDisplayList() gets called continuously with an ever increasing width argument. I let it go above 100,000 before I closed the browser window. I've switched the code to use the w and h args that get passed in as well but it still happens. Now that we know what the problem is how do we figure out the why and how to prevent it?
Thanks, Ben On Fri, Mar 14, 2008 at 1:42 PM, Alex Harui <[EMAIL PROTECTED]> wrote: > Assuming you've sized the button before you hit this code, you are also > in danger if there is a scale factor applied to the component. We recommend > using the unscaledWidth/Height parameters passed into updateDisplayList > instead of this.width/height as they are not affected by scale. > > Setting a child's x,y will trigger invalidation in some containers. > Normally, the invalidateDisplayListFlag is still set at this time which > prevents another invalidation pass. However, if it affects the scrollbar > calculation it could ripple back up and make the parent think about its size > again. > > If scrollPolicy="on" the scrollbar is factored into the measurements. If > not, it isn't. > > I would check the numbers you are using and see if that updateDL gets > called over and over and what numbers it gets. > > -Alex > > ------------------------------ > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Ben Clinkinbeard > *Sent:* Friday, March 14, 2008 10:30 AM > *To:* [email protected] > *Subject:* Re: [flexcoders] Re: Why are modules so buggy? > > So (unsurprisingly) I tried a shortcut and it seems like your scrollbar > theory is correct. I first tried setting the scroll policies of demon > button's parent to off but that didn't help. I then changed demon button's > positioning (in updateDisplayList()) to 0, 0 and that fixed the issue. Its > nice to have it showing the module but I can't be too excited since the > positioning obviously can't stay at 0, 0. > > The original lines from inside updateDisplayList() look like this: > > nextBtn.x = this.width - nextBtn.width - 15; > nextBtn.y = ( this.height - nextBtn.height ) / 2; > > Seems reasonable to me, am I missing something? > > Thanks yet again! > Ben > > > On Fri, Mar 14, 2008 at 12:20 PM, Alex Harui <[EMAIL PROTECTED]> wrote: > > > OK, that smells like invalidation loops. At the end of the > > validation pass something remains invalidated so we do another validation > > pass, but something still ends up invalidated, so we…. > > > > > > > > Until we get a complete validation, the app won't show, and after app > > startup, until a new component finishes validation, it won't show up. > > > > > > > > I debug this by setting a breakpoint in > > LayoutManager.doPhasedInstantiation. If you try it on a test app, you > > should see that it gets called 3 to 8 times and stops when the app shows up. > > If you have an invalidation loop, it never stops getting called, and then I > > debug into it to see who keeps ending up dirty and then try to figure out > > why. > > > > > > > > Your demon button could be forcing some edge condition where scrollbars > > show up then go away (hysteresis). > > > > > > > > -Alex > > > > > > ------------------------------ > > > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > > Behalf Of *ben.clinkinbeard > > *Sent:* Friday, March 14, 2008 6:54 AM > > *To:* [email protected] > > > > *Subject:* [flexcoders] Re: Why are modules so buggy? > > > > > > > > Hi Alex, > > > > We are using ModuleLoader so the GC thing shouldn't be an issue. (I > > tried it with ModuleManager this morning to no avail either.) > > > > The animation is just a placeholder at this point so its just a 10 > > frame tween created in Flash CS3 with a stop() at the beginning and > > end. When it finishes loading we tell it to play(). The speedup is > > only present when I add the demon button with addChild() instead of > > rawChildren.addChild() so I don't think it is related to any > > intentional framerate increases. > > > > I did what you suggested and checked that the module exists, has the > > correct parent, correct x, y, width and height and all of those > > properties return the expected values. Not sure what you mean about > > checking invalidation flags though. > > > > More weirdness in today's testing: Our basic setup is that we have a > > few ModuleLoaders that are on stage and sized but have visibility set > > to false and we don't give them a url value until we want them to > > load. When they've finished loading we turn them visible. If I set > > visible to true and set url to the specified module swf the > > application never gets out of frame one. The progress bar shows the > > load completing in the sense that the bar is full width but thats it. > > The progress bar stays on stage and the app just sits. We never see > > our actual application stage. > > > > So. Con. Fused. > > > > Thanks for your help, > > Ben > > > > --- In [email protected] <flexcoders%40yahoogroups.com>, "Alex > > Harui" <[EMAIL PROTECTED]> wrote: > > > > > > Well, it doesn't ring any bells, but someone else hit a problem where > > > they were loading the module twice and timing issues from the module > > > being cached in the browser cache affected whether it worked or not. > > > > > > > > > > > > The classic no-show problem is when the IModuleInfo handle returned > > from > > > ModuleManager is kept only in a local variable to the function that > > > calls ModuleManager.getModule Then a GC can punt the module and that > > > can happen "randomly". If you are using ModuleLoader, you won't run > > > into this problem. > > > > > > > > > > > > How does the animation SWF work? Is it code-based, frame-based, > > > timer-based? We pump up the frame-rate during app startup, so that > > > could affect animations. > > > > > > > > > > > > I guess I would start by proving after no-show that the module > > actually > > > exists, and introspect it for sizes, parenting, invalidation flags, > > etc. > > > > > > > > > > > > ________________________________ > > > > > > From: [email protected] <flexcoders%40yahoogroups.com>[mailto: > > [email protected] <flexcoders%40yahoogroups.com>] On > > > Behalf Of ben.clinkinbeard > > > Sent: Thursday, March 13, 2008 8:00 PM > > > To: [email protected] <flexcoders%40yahoogroups.com> > > > Subject: [flexcoders] Re: Why are modules so buggy? > > > > > > > > > > > > Thanks Alex. Unfortunately, and as usually seems to be the case, this > > > is happening inside of a fairly complex structure. Something else I > > > just noticed though is also strange. When the app loads we have a SWF > > > that gets loaded and plays an animation before presenting a button > > > that can be clicked which takes you to the module. When the problem > > > arises as I originally described, the intro animation also plays much > > > quicker than usual. Its at least twice as fast as the SWF plays when > > > the problem is not present. > > > > > > Does that give you any clues? > > > > > > Thanks, > > > Ben > > > > > > --- In [email protected] <flexcoders%40yahoogroups.com><mailto: > > flexcoders%40yahoogroups.com> > > > , "Alex Harui" <aharui@> wrote: > > > > > > > > It is a known bug that % width/height doesn't work in modules and > > > using > > > > percentWidth/Height is the workaround. > > > > > > > > > > > > > > > > Can't think of any reason for the second behavior. I'll look at a > > test > > > > case if you want. > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: [email protected] <flexcoders%40yahoogroups.com><mailto: > > flexcoders%40yahoogroups.com> > > > [mailto:[email protected] <flexcoders%40yahoogroups.com><mailto: > > flexcoders%40yahoogroups.com> > > > ] On > > > > Behalf Of ben.clinkinbeard > > > > Sent: Thursday, March 13, 2008 7:04 AM > > > > To: [email protected] <flexcoders%40yahoogroups.com><mailto: > > flexcoders%40yahoogroups.com> > > > > Subject: [flexcoders] Why are modules so buggy? > > > > > > > > > > > > > > > > I've admittedly only been using them for a short time but they seem > > > > phenomenally fickle. Our basic setup is that we have States defined > > in > > > > the main app, each of which holds a module and sets its visibility > > > > accordingly. Couldn't be much more straightforward. > > > > > > > > The other day my module stopped appearing when I set the layout > > > > property of one of its child components (TeaserWindow). The way I > > > > ended up fixing it was by changing the mx:Module tag from > > width="100%" > > > > height="100%" to percentWidth="100" percentHeight="100". > > > > > > > > Today my module has stopped showing up when I changed one of > > > > TeaserWindow's child components (a Button) from being added to > > > > rawChildren to being added as a regular child. TeaserWindow has 3 > > > > child buttons and only this specific one being in children causes > > this > > > > issue. The (totally illogical) "fix" of using percentWidth and > > > > percentHeight is not preventing this latest absurd behavior. > > > > > > > > I am at a complete loss as to how the child composition of a child > > of > > > > the Module or the layout mode of a child could cause the entire > > module > > > > not to show. Note that even when it doesn't show it reports its > > > > visible property as true and width and height as being correct. > > > > > > > > Am I taking crazy pills? > > > > > > > > > > > > >
