You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by "Noel Grandin (JIRA)" <ji...@apache.org> on 2011/04/28 15:30:03 UTC
[jira] [Resolved] (PIVOT-735) Strange problem with textarea
[ 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
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Greg Brown <gk...@verizon.net>.
> No, that's not the case.
Well, it's supposed to be, since that's the way I designed it to work. :-)
> I think there is a design pattern mismatch here.
> We have the general situation that our getPreferredSize() methods never update internal layout information fields.
> But TextAreaSkin is violating that assumption in the way that it uses ParagraphView.
> The correct fix IMO is to create getPreferredSize() methods on ParagraphView, so that ParagraphView can know to do the
> necessary calculations without updating it's internal structures.
I have thought about that. But that would have a negative impact on performance since we'd be calling it twice (once to calculate size and once to lay out). That is necessary for components, but not for text. Text is always given its "preferred" size, so no "negotiation" is necessary.
So maybe your fix is correct. We simply tell the paragraph view what its break width is every time we need size info from it, and if that causes it to invalidate and recalculate, so be it.
G
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Noel Grandin <no...@gmail.com>.
No, that's not the case.
the high level logic looks something like this:
masterPaint() {
if (something_changed()) validate();
paint();
}
But in this case nothing changed, so validate() is not called.
The problem is that higher level code called getPreferredSize(), which called TextAreaSkinParagraphView#setBreakWidth
and TextAreaSkinParagraphView#validate, which results in ParagraphView updating it's internal layout structures, which
means that when the next paint() happens, ParagraphView is attempting to perform a paint() operation with incorrect
internal layout information.
I think there is a design pattern mismatch here.
We have the general situation that our getPreferredSize() methods never update internal layout information fields.
But TextAreaSkin is violating that assumption in the way that it uses ParagraphView.
The correct fix IMO is to create getPreferredSize() methods on ParagraphView, so that ParagraphView can know to do the
necessary calculations without updating it's internal structures.
-- Noel.
Greg Brown wrote:
> 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
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Greg Brown <gk...@verizon.net>.
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
>>
>
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Greg Brown <gk...@verizon.net>.
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
>
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Noel Grandin <no...@gmail.com>.
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
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Greg Brown <gk...@verizon.net>.
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
>
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Noel Grandin <no...@gmail.com>.
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
Re: [jira] [Resolved] (PIVOT-735) Strange problem with textarea
Posted by Greg Brown <gk...@verizon.net>.
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