Hi Alex,
the component hierarchy:
<component>
__<skin>
____<group>
______<group id="contentGroup">
________<child />
________<child />
________<child />
________<child />
______<contentGroup>
____</group>
__</skin>
</component>
There is no specific layout applied, since an absolute positioning is required.
Now when setting the positions of <child /> elements programmatically with the
API of the ILayoutElement interface, the width and height values are not set
properly for the contentGroup. contentWidth and contentHeight have the right
values. I have to register an event handler for FlexEvent.UPDATE_COMPLETE and
invalidate the contentGroup again. After the additional invalidation cycle,
width and height are set as expected.
I'll post an example tomorrow.
--- In flexcoders@yahoogroups.com, Alex Harui <aha...@...> wrote:
>
> I may not be understanding your issue. I'm pretty sure our
> SkinnableContainers delegate their assigned layouts to the contentGroup
> because the contentGroup's measurements affect the size given to it by its
> parent and the eventual call to updateDisplayList. If you subclass
> updateDisplayList in the SkinnableComponent I don't see how the assigned
> layout will know that its measurement is not right.
>
> One way to encapsulate the measurement and layout logic together is to create
> a custom layout. I suppose you could also just override measure() in the
> component as well.
>
>
> On 5/31/10 12:34 AM, "Florian" <florian.saliho...@...> wrote:
>
>
>
>
>
>
> Hi Alex, usually i would agree right on spot but the fact that i am using a
> basic layout in for group and the layouting is done correctly, i don't really
> see the need for another class. There is just one update of the measuring
> missing, which i don't understand.
>
> When a Group is using a BasicLayout contentWidth and contentHeight should be
> equal with width and height, if clipping is not enabled and no values for
> width or height are set explicitly. Or am i mistaken in this point?
>
> Best regards and thanks for taking the time.
>
> --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ,
> Alex Harui <aharui@> wrote:
> >
> > I would create a new Layout class and properly measure and layout in its
> > measure() and updateDisplayList() methods and use that as the
> > contentGroup's layout, otherwise the Group's default layout class is going
> > to be arguing with your code.
> >
> >
> > On 5/30/10 3:36 AM, "Florian" <florian.salihovic@> wrote:
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > i was and i am still running into problems with sizing and placing
> > components in skins programmatically for spark ActionScript and
> > MXML/ActionScript components.
> >
> > I want to initialize the components in MXML and size and position the
> > children in the component's (a component's skin) updateDisplayList,
> > although this might be a bit of an uncommon approach.
> >
> > I was implementing the positioning via UIComponent.move, which i realized
> > was the wrong approach. After just setting the x and y properties, i did
> > some research and stumbled across the ILayoutElement and its methods like
> > setLayoutBoundsPosition and corresponding methods to modify the skin's
> > display list. But somehow the group, which contains the children, does not
> > propagate its new size up to its parent. I use the updateComplete event to
> > invalidate the group's size and force the layout to be calculated properly
> > a last time. The view looks as expected. But i don't think that
> > invalidating a component "a last time" after an updateComplete event was
> > dispatched is wrong.
> >
> > Now, what is the right approach for the following task: implementing a
> > skinnable component and a corresponding skin. The skin creates the skin
> > parts in MXML in a Group (id="contentGroup") but the layout is calculated
> > within the skin's updateDisplayList method.
> >
> > I only found one useful article on the web, which is not really a lot of
> > information at all
> > (http://www.adobe.com/devnet/flex/articles/spark_layouts_print.html).
> >
> > Best regards.
> >
> >
> >
> >
> >
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe System, Inc.
> > http://blogs.adobe.com/aharui
> >
>
>
>
>
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe System, Inc.
> http://blogs.adobe.com/aharui
>