layout() is called whenever the component is validated. A component starts out in an invalid state, so at least one call to layout() is guaranteed. After that, a call to layout() will follow any call to invalidate(). As you said, this should happen any time something that affects the component's layout is changed. So it is possible that something that should cause an invalidate is not actually triggering one.
On Apr 28, 2011, at 10:41 AM, Noel Grandin wrote: > > As far as I can tell, layout() is only called on a component when something > about the layout structure of that component > changes. > So it doesn't seem necessarily true that paint() is always preceded by > layout(). > > -- Noel. > > Greg Brown wrote: >> OK. It is a small patch that seems to fix the issue, so that's good - but I >> have to wonder if it is the "right" fix. A call to layout() should precede >> any call to paint(), at which point the break widths should be updated. If >> that's not happening, it may point to an issue elsewhere. >> G >> >> On Apr 28, 2011, at 9:57 AM, Noel Grandin wrote: >> >>> Hi >>> >>> The various getPreferred methods were calling setBreakWidth() on the >>> ParagraphView class, which meant that the >>> breakWidth variable and other associated layout data in >>> TextAreaSkinParagraphView was left in an incorrect state when >>> later paint operations were performed. >>> >>> I fixed it so that paint() always calls setBreakWidth and validate(), to >>> restore the data to a correct state. >>> >>> Another way of fixing it that just occurred to me, would be to make the >>> getPreferred methods deep-copy the ParagraphView >>> class before using it to calculate preferred sizes. >>> >>> -- Noel. >>> >>> Greg Brown wrote: >>>> Hi Noel, >>>> Thanks for fixing this. I looked at the fix but it wasn't immediately >>>> clear what the problem was. Would you mind summarizing? >>>> Thanks, >>>> Greg >>>> >>>> On Apr 28, 2011, at 9:30 AM, Noel Grandin (JIRA) wrote: >>>> >>>>> [ >>>>> https://issues.apache.org/jira/browse/PIVOT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>>> ] >>>>> >>>>> Noel Grandin resolved PIVOT-735. >>>>> -------------------------------- >>>>> >>>>> Resolution: Fixed >>>>> Assignee: Noel Grandin >>>>> >>>>> Fixed in rev 1097451 >>>>> >>>>>> Strange problem with textarea >>>>>> ------------------------------ >>>>>> >>>>>> Key: PIVOT-735 >>>>>> URL: https://issues.apache.org/jira/browse/PIVOT-735 >>>>>> Project: Pivot >>>>>> Issue Type: Bug >>>>>> Components: wtk >>>>>> Affects Versions: 2.0 >>>>>> Environment: windows 7 x64 >>>>>> Reporter: Olivier Dutrieux >>>>>> Assignee: Noel Grandin >>>>>> Labels: textarea >>>>>> Fix For: 2.0.1 >>>>>> >>>>>> Attachments: sample.zip, screenshot-1.jpg >>>>>> >>>>>> >>>>>> I have a textarea with scrollpane like this : >>>>>> <ScrollPane horizontalScrollBarPolicy="fill" >>>>>> verticalScrollBarPolicy="fill_to_capacity" maximumHeight="100" >>>>>> preferredWidth="350"> >>>>>> <TextArea text="Lorem ipsum ..."/> >>>>>> </ScrollPane> >>>>>> If I hide a component on the my window page where there is this >>>>>> textarea, the text of textarea change to be display under the scrollpane. >>>>> -- >>>>> This message is automatically generated by JIRA. >>>>> For more information on JIRA, see: http://www.atlassian.com/software/jira >
