> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `updateItem` method.
> This PR will immediately resize
On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote:
>> @johanvos
>> As requested, we've made a unit test, which tests this bug.
>> It's based on your test and our original test class. It can be added to the
>> ListViewTest.
>> You can find it, in the JDK ticket.
>>
>> Btw, adding the cells
On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote:
>> @johanvos
>> As requested, we've made a unit test, which tests this bug.
>> It's based on your test and our original test class. It can be added to the
>> ListViewTest.
>> You can find it, in the JDK ticket.
>>
>> Btw, adding the cells
On Mon, 25 Apr 2022 09:00:54 GMT, Florian Kirmaier
wrote:
>> I agree with that observation. The mathematical perfect situation would be
>> to pre-calculate the height of all items, so that the scrolbar position can
>> be exact, and the content placing can be exact as well. That would be at
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `updateItem` method.
> This PR will immediately resize
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
On Thu, 14 Apr 2022 08:52:27 GMT, Johan Vos wrote:
>> Johan Vos has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't shift cells if we are already showing the lowest index cell.
>
> I agree with that observation. The mathematical
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
On Fri, 25 Mar 2022 16:26:34 GMT, Kevin Rushforth wrote:
> It looks like there are some failing unit tests now.
I fixed them.
-
PR: https://git.openjdk.java.net/jfx/pull/712
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `updateItem` method.
> This PR will immediately resize
On Thu, 24 Mar 2022 10:06:34 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
On Tue, 22 Mar 2022 08:47:42 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `updateItem` method.
> This PR will immediately resize
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `updateItem` method.
> This PR will immediately resize
On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote:
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the
On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote:
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the
When the size of a ListCell is changed and a scrollTo method is invoked without
having a layout calculation in between, the old (wrong) size is used to
calculcate the total estimate. This happens e.g. when the size is changed in
the `updateItem` method.
This PR will immediately resize the cell
20 matches
Mail list logo
