thanks Serkan - you are right - I did not see that explanation earlier (just the screencaptures) which is why I asked my extra question.
It sounds like it could be similar to what I was addressing, but I don't have a 'universal' solution (and possibly not even a 'good' selective solution, which is why I am keen for extra eyes on it), but it might be useful as-is, or possibly give Alex, you or anyone else some other approaches to consider. I am happy to collaborate on an approach once we settle on one that makes sense for all of us. On Fri, Jun 5, 2020 at 2:29 PM serkan <[email protected]> wrote: > > I am not sure but I guess mail not sent to the list Greg :) > > My application heavily use states to manage visual layout Greg. Alex is > working on the issues one by one as open an issue. > > They are mostly with percentage based. > > e.g. > > <jobdetail:JobAllDetailPanel includeIn="jobDetailState" id="allJobDetail" > height="100%"/> > > This component is the one et the center with name "İş Tüm Detay Formu" > which is very ugly displayed in Royale. > > Some fix works at first like menu bar but as you can see when resize, it > is broken again :) > > Thank > Serkan > > 4.06.2020 13:08 tarihinde Greg Dove yazdı: > > > Thanks Serkan, > > Do you think you are seeing the same type of issue I described? Are any of > those controls being added either via states or via code at runtime into > containers that have percentage based dimensions? > > I think that the changes I have won't break anyone's existing layouts, but > I am not sure yet if I should push them as is to develop or not, because > this is the first time I looked at emulation layout stuff. > I do see improvements for the issues I have been facing, but there still > might be more things that need attention, or I may not be addressing things > in the right way. > > @aharui : when you get to see this, what do you think? Would you have time > to take a look at this? And do you think I can push what I have to develop > or should it go in a branch? > (I can monkey patch my client project so we can use these 'fixes' for > local progress in the interim if I need to). > > > > > > > On Thu, Jun 4, 2020 at 8:52 PM serkan <[email protected]> wrote: > >> Hi Greg, >> >> Yes I am. >> >> Here is my case : >> Flex: >> >> >> >> Emulation : >> >> >> >> Thanks, >> Serkan >> >> 4.06.2020 11:12 tarihinde Greg Dove yazdı: >> >> Hi, >> >> Just wondered if anyone else is dealing with layout issues in Flex >> emulation. I have some layout issues that are slowing my progress on a >> project, and I'd like to resolve them as quickly as I can. >> >> In particular, I see issues with BoxLayout-based containers which have >> percentWidth or percentHeight set. These don't get determined as having >> width or height 'SizedToContent' when performing layout, but in many >> situations they behave in a similar way (they can change their size based >> on their content in terms of layout rules applied by the parent container). >> This is because in Flex, percentages are not simply a percentage of their >> parent, but they follow something perhaps a little closer to flexbox layout >> rules for all the percentWidth or percentHeight siblings (managed by their >> parent's layout). In other words, they are also related to the measured >> size of their content if the parent needs to manage them (I'm not sure how >> best to describe this, but I think that sort of captures it). They can >> expand beyond their percent allocation or contract below it depending on >> their measured sizes. >> I think the layouts work downward for this, but changes in the children >> don't seem to trigger the parent layout. >> >> An example might be >> <mx:HBox id='addThingsToMe' width='50%' /> >> >> If you have the above at the application level (where the application has >> vertical layout) and keep adding buttons (for example) to the HBox via a UI >> test button that adds a new Button to that on each click, then it should >> expand horizontally greater than 50% width when the volume of buttons >> exceeds its nominal 50% width. It is definitely easier to see this if you >> add a border to the container. >> >> I have been working on this, and made progress, but the approach I am using >> feels a bit patchwork, and just wondered whether others are seeing anything >> like this, and/or how it has been addressed elsewhere.... >> >> Here's a summary of some of the things I have been trying, which do yield >> improvements, but don't really solve the problem completely: >> >> 1. added extra listener for 'childrenRemoved' in BoxLayout strand setter. >> >> 2. Created a new mx 'ContainerView' class >> (mx.containers.beads.ContainerView extends >> org.apache.royale.html.beads.ContainerView) >> This has the following in it: >> >> private var widthBefore:Number = -1 >> private var heightBefore:Number = -1; >> private var sizeChangedBeforeLayout:Boolean; >> >> COMPILE::JS >> override public function beforeLayout():Boolean >> { >> var container:Container = host as Container; >> >> sizeChangedBeforeLayout = (widthBefore != container.width || heightBefore >> != container.height); >> widthBefore = container.width; >> heightBefore = container.height; >> return super.beforeLayout(); >> } >> >> COMPILE::JS >> override public function afterLayout():void >> { >> var container:Container = host as Container; >> //size might change during layout >> var sizeChangedDuringLayout:Boolean = !sizeChangedBeforeLayout && >> (widthBefore != container.width || heightBefore != container.height); >> if (sizeChangedDuringLayout) { >> //prepare for next time >> widthBefore = container.width; >> heightBefore = container.height; >> } >> var requestParentLayout:Boolean = sizeChangedBeforeLayout >> || sizeChangedDuringLayout >> || (!isNaN(container.percentWidth) && container.width < >> container.measuredWidth) || (!isNaN(container.percentHeight) && >> container.height < container.measuredHeight); >> if (requestParentLayout && container.parent is Container) { >> trace('requesting parent layout of ',(container as >> Object).ROYALE_CLASS_INFO.names[0].qName ); >> (container.parent as Container).layoutNeeded(); >> } >> } >> >> That is pretty much it, and it is being used as a replacement in my local >> MXRoyale css for Container: >> >> /*IBeadView: >> ClassReference("org.apache.royale.html.beads.ContainerView");*/ >> IBeadView: ClassReference("mx.containers.beads.ContainerView"); >> >> I'm not saying this is right, but it does help quite a bit with what I am >> facing. >> >> In addition to BoxLayout in general, I have been working on the >> Grid/GridRow/GridItem layouts which are more specific in terms of layout >> changes needed, but also can have similar problems. >> >> >> Although I am seeing improvements with what I have done so far, I'm not >> really satisfied with it, and I am keen for input/discussion (or >> collaboration). I have been pursuing what I would mostly describe as a >> 'workaround' approach, so would welcome any thoughts on how best to tackle >> this. >> I think there is something missing because of the way Flex does layouts vs. >> the way Royale does it, but I can't describe it fully yet. Perhaps things >> are only currently envisaged to work with mxml declarative content onto >> display and not so much with dynamic updates. But I think state-based >> changes could have similar effects for some of these things if they happen >> inside containers that have their own percent dimensions. >> >> >> Thanks, >> Greg >> >> >> >> >
