To put it another way, the design expects that a call to paint() will be preceded by a call to layout(). So if this isn't happening, then there is probably a bug somewhere. G
On Apr 28, 2011, at 10:56 AM, Greg Brown wrote: > 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 >> >
