What is the class who's updateDL is overridden? It feels like the module's measuredWidth/Height is driven by the right side of the child. As you center you push the child to the right so the container says it wants to be wider and then you push again...
________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ben Clinkinbeard Sent: Friday, March 14, 2008 10:54 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Why are modules so buggy? 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] <mailto:[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: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> ] On Behalf Of Ben Clinkinbeard Sent: Friday, March 14, 2008 10:30 AM To: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> 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] <mailto:[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: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> ] On Behalf Of ben.clinkinbeard Sent: Friday, March 14, 2008 6:54 AM To: flexcoders@yahoogroups.com <mailto:flexcoders@yahoogroups.com> 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 flexcoders@yahoogroups.com <mailto: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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of ben.clinkinbeard > Sent: Thursday, March 13, 2008 8:00 PM > To: flexcoders@yahoogroups.com <mailto: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 flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto: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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > > [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > > ] On > > Behalf Of ben.clinkinbeard > > Sent: Thursday, March 13, 2008 7:04 AM > > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto: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? > > >
