I have created an infinite list using
LayoutMode="PreserveVisual" and when removing leading items and appending items to the end of the list the last four appended items get rendered twice (the length of list data is correct but the extra rows are rendered below the intended list items).
When appending more items the extra artifacts are still visible at the end of the new list, but no new items are added. The extra items appear to affect the
When downgrading to Fuse 0.29 list rendering works as expected.
Interesting. Can you please upload a test case that demonstrateshe this?
How to reproduce:
1 Scroll down to bottom to add rows to the list
2 Click the header to halt row adding on scroll
3 Scroll to bottom
With Fuse 0.29 (expected behaviour):
- the numbers in the rows have a continuous sequence
With Fuse 0.30 (buggy behaviour):
- the last row(s) is out of sequence
Also want to make a plug for this feature request https://www.fusetools.com/community/forums/feature_requests/sticky_panel_animation It would save sooo much complexity not having to recalculate all the scroll animations to get sticky headers (as you can see in the posted example).
Thanks for the test case, we will investigate.
I’m looking at this now. The halting of row addition is not related to the issue, these out-of-order rows are already there, just hidden beyond view. If you’re like to see this you can modify the Panel/ScrollView setup slightly:
<Panel Padding="20,20,20,300" Color="#FAA">
<Stroke Width="2" Color="#000"/>
<ScrollView ux:Name="view" LayoutMode="PreserveVisual" ClipToBounds="false"
This will show the parts of the
ScrollView that are beyond the end – I often do such setups when trying to debug such issues.
I’m gonig to continue looking now for what is placing these rows out-of-order.
Correct! The pausing of row adds was only intended to allow you to scroll to the bottom of the page and see the result. It wasn’t part of the issue.
My guess was that it is a rendering bug related to the PreserveVisual render mode since the length of the Observable list containing the data to render was correct but the number of visual rows was too high. But it also appears that the rendering engine is aware of the extra rows because the scroll triggers fire relative to the end of the (incorrectly) rendered extra items.
BTW smart way to debug the boundaries of the ScrollView, will use that in the future.
Is there any estimate on when this bug will be resolved and shipped? I am trying to plan a release, but this bug is a show stopper and I had other issues with the earlier version.
This should be fixed in the version that is being tested now, the pre-release version. Thus it should be out soon. It was an error in the Observable code dealing with lists.
That sounds awesome! Really looking forward to this release
Sorry for sounding like a record on repeat, but when can we expect the next Fuse release? I know you have some big plans for that release, but I am really, really looking forward to finish up my app so I can ship it and this is my show stopper…
You can download the pre-release from eda-qa’s link above (https://www.fusetools.com/downloads/channel/qa)
I can confirm that this bug is fixed in the pre-release!