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? > > > > > > > >
