Alex, is there a reason CanvasLayout measures centered content from its current position instead of 0,0? What I mean is, does something else rely on that behaviour that you know of? I'd like to file a change request, but I don't wanna waste the time of the Adobe guys if there's no chance of it being changed because it's a required behaviour, no matter how silly it seems to me :)
-Josh On Fri, Jun 20, 2008 at 3:29 PM, Josh McDonald <[EMAIL PROTECTED]> wrote: > I'm building a Container (SnapinContainer), which in future I'd like to be > able to extend to put anything into. But it's specifically designed to > contain several instances of another container (Snapin), which doesn't > itself extend canvas, but puts its children in a canvas because I'm hiding a > lot of voodoo from less experienced Flex developers who need to be able to > build Snapins with the visual editor in Builder, and I want them to be able > to use styles for layout. > > You're right that for now I can make the Snapin class use a subclass of > Canvas with a different measure method, but that doesn't help me use it for > any component, nor does it help if a developer decides for whatever reason > to put a Canvas in their Snapin. > > If there were an easy way to call measure() and updateDisplayList() in a > UIComponent I could just emulate the system as it is, and for children of > SnapinContainer simply keep calling them in a loop until I get a stable > answer, and use that. > > The problem stems from the fact that I re-order the children of > SnapinContainer based on their size, it's suppose to organise things in the > best way it can to make best use of the visible real estate. But many of its > children will be setActialSized larger than measured because the whole point > of it is to keep things looking neat, and we want them to line up. > > -Josh > > > On Fri, Jun 20, 2008 at 3:16 PM, Alex Harui <[EMAIL PROTECTED]> wrote: > >> What do you need Canvas for? Can you just use a custom Container with a >> better measure() method? >> >> >> ------------------------------ >> >> *From:* [email protected] [mailto:[EMAIL PROTECTED] *On >> Behalf Of *Josh McDonald >> *Sent:* Thursday, June 19, 2008 9:48 PM >> >> *To:* [email protected] >> *Subject:* Re: [flexcoders] Problems with updateDisplayList() and >> measure() and infinite loops + bug in CanvasLayout? >> >> >> >> The problem is that I'm building a container that can in theory contain >> anything, but will definitely contain things that contain Canvases. I guess >> I'm stuck cooking up a hack... :) >> >> -Josh >> >> On Fri, Jun 20, 2008 at 2:39 PM, Alex Harui <[EMAIL PROTECTED]> wrote: >> >> Sorry, I wasn't clear. Canvas doesn't factor out centering and you end up >> in an infinite loop. My recommendation is that you supply a custom >> measure() method that factors out the centering. >> >> >> ------------------------------ >> >> *From:* [email protected] [mailto:[EMAIL PROTECTED] *On >> Behalf Of *Josh McDonald >> *Sent:* Thursday, June 19, 2008 9:32 PM >> *To:* [email protected] >> *Subject:* Re: [flexcoders] Problems with updateDisplayList() and >> measure() and infinite loops + bug in CanvasLayout? >> >> >> >> Actually given it first grows to 160, then goes back to 161, it's waiting >> until the measure() is within one pixel :) >> >> resized to 100 x 50 >> resized to 130 x 50 >> resized to 145 x 50 >> resized to 153 x 50 >> resized to 157 x 50 >> resized to 159 x 50 >> resized to 160 x 50 >> >> resized to 400 x 200 >> resized to 280 x 109 >> resized to 220 x 64 >> resized to 190 x 50 >> resized to 175 x 50 >> resized to 168 x 50 >> resized to 164 x 50 >> resized to 162 x 50 >> resized to 161 x 50 >> >> >> -Josh >> >> On Fri, Jun 20, 2008 at 2:30 PM, Josh McDonald <[EMAIL PROTECTED]> wrote: >> >> That what I thought it should do, but it doesn't. Here's a simple test >> case: >> >> <?xml version="1.0" encoding="utf-8"?> >> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"; >> layout="absolute"> >> >> <mx:Canvas backgroundColor="blue" id="container" >> resize="trace('resized to ' + event.target.width + ' x ' + >> event.target.height)"> >> <mx:Button width="100" height="50" label="Button"/> >> <mx:Label text="This is text, it's wider than the button!" >> width="160" id="lb" horizontalCenter="0" verticalCenter="0"/> >> </mx:Canvas> >> >> <mx:Button click="trace('');container.setActualSize(400,200)" >> label="Mess It up" horizontalCenter="0" verticalCenter="0"/> >> >> </mx:Application> >> >> Unless I'm mistaken, It shows that when the current size is not the >> correct measure size (as it gets bigger on creationComplete, or as it gets >> smaller when you click "mess it up"), you get a loop of updateDisplayList(), >> measure(), etc until updateDisplayList() is followed by a measure() that >> reports the same size that was last passed to updateDisplayList(). >> >> -Josh >> >> >> >> On Fri, Jun 20, 2008 at 2:12 PM, Alex Harui <[EMAIL PROTECTED]> wrote: >> >> Measure() should return the bound of the children factoring out centering >> offsets. >> >> >> ------------------------------ >> >> *From:* [email protected] [mailto:[EMAIL PROTECTED] *On >> Behalf Of *Josh McDonald >> *Sent:* Thursday, June 19, 2008 7:21 PM >> *To:* [email protected] >> *Subject:* [flexcoders] Problems with updateDisplayList() and measure() >> and infinite loops + bug in CanvasLayout? >> >> >> >> Hey guys, >> >> I've got a problem with some layout code I'm working on. I'm positioning a >> bunch of components, and their positions are determined by their measured >> size. However they are also being expanded larger that their measured size >> on occasion, which sends me into an infinite loop whenever one of my >> containers contains anything that's centred. >> >> I've figured out that this is due to CanvasLayout.measure() measuring >> children with horizontalCenter / verticalCenter at their current position, >> rather than at 0,0 which would make more sense to me. Not much I can do >> about this. It smells like a bug, but it might be on purpose. >> >> What should I do to combat this problem? I was thinking maybe setting a >> flag on updateDisplayList, that will make the next call to measure() return >> the same size no matter what, but that seems like a hack to me. And if >> there's an occasion where updateDisplayList() isn't followed immediately by >> measure() it'll break, and various other things just make it seem very >> frail. >> >> Has anybody come up against this sort of thing before? How did you tackle >> it? >> >> Cheers, >> >> -Josh >> >> -- >> "Therefore, send not to know For whom the bell tolls. It tolls for thee." >> >> :: Josh 'G-Funk' McDonald >> :: 0437 221 380 :: [EMAIL PROTECTED] >> >> >> >> >> -- >> "Therefore, send not to know For whom the bell tolls. It tolls for thee." >> >> :: Josh 'G-Funk' McDonald >> :: 0437 221 380 :: [EMAIL PROTECTED] >> >> >> >> >> -- >> "Therefore, send not to know For whom the bell tolls. It tolls for thee." >> >> :: Josh 'G-Funk' McDonald >> :: 0437 221 380 :: [EMAIL PROTECTED] >> >> >> >> >> -- >> "Therefore, send not to know For whom the bell tolls. It tolls for thee." >> >> :: Josh 'G-Funk' McDonald >> :: 0437 221 380 :: [EMAIL PROTECTED] >> >> >> > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
