Paul > I'm not really sure what that is all about, Background isn't chrome it is background. Children need to be in front of background.
I have a spec where I need another background behind the view children and in front of the border. Trust me, I have 1000's of hours of investigation into this. This applies if you are doing low level coding in the framework. Not to mention, when the container holds more then 1 view child, the children get put into a content pane. It is impossible to get something behind child 0 without using this hack. Jesse, with the text area, after removing it from the display list did you set; textField = null; ?? Peace, Mike On 3/11/07, Jesse Warden <[EMAIL PROTECTED]> wrote:
Grr... works for everything but my Label. Keeps whining about antiAlias being null. Had this happen last night (this morning?) when the TextField isn't in the DisplayList, but gets measure called on 'em. Fuggit, everything else works; thanks a bunch Michael! On 3/11/07, Jesse Warden <[EMAIL PROTECTED]> wrote: > > Thanks Michael, I'll try your code. > > Paul, if you look in mx.containers.Container, you can see how they > override and abstract the DisplayList API so that you have 2 types of > children; raw and regular. This allows you to have "those you put in > Canvas" and "those that make Panel". For example, the title bar, close > button, title, etc. are NOT something you want inside your Panel container > to interact with your children. If you put a CheckBox control into a Panel, > you would expect only 1 child to be in your container (numChildren, > getChildAt(0), etc.). This allows you to build container components for > others to use without "knowing" how your child setup works. > > On 3/11/07, Paul DeCoursey < [EMAIL PROTECTED]> wrote: > > > > I'm not really sure what that is all about, Background isn't chrome > > it > > is background. Children need to be in front of background. I know at > > one point I was having trouble with a background rendering over some > > graphical elements that I had. So to fix that I did my graphical > > elements on a child item, that way the canvas background rendered > > behind my content. I'm not sure you have the same issue, but perhaps > > you could use that technique to solve your issue. Create a container > > with two children, one for display elements and one for chrome. Add > > the chrome first and the children second and your children will be > > above the chrome. > > > > Paul > > > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, > > "Jesse Warden" <[EMAIL PROTECTED]> wrote: > > > > > > I'm extending Canvas. His base class, Container, decrees on line > > 4608 that > > > all children are behind chrome. I want the opposite. I want my > > chrome > > > BEHIND the content; I want the content IN FRONT of my chrome. > > > > > > However, since Container does all kinds of crazy over-writting of > > > DisplayObject methods and tucks them away in mx_internal and various > > other > > > private & final prefix's, I have no clue how to easily make my > > chrome inside > > > of rawChildren go backwards. Obviously, setChildIndex doesn't work > > at this > > > point because the base class owns those methods as proxies now. > > > > > > The hack, for now, is to NOT have my chrome draw a background. If it > > > doesn't, I can click on children just fine. That, however, sucks > > because I > > > want a background. Figured 2nd hack is to just set the > > backgroundColor > > > property to my chrome's background, and redraw my chrome as a mask > > for the > > > background. That is worse. > > > > > > Suggestions? > > > > > > > >
-- Teoti Graphix http://www.teotigraphix.com Blog - Flex2Components http://www.flex2components.com You can find more by solving the problem then by 'asking the question'.
