Enhance logical scrolling by using logial units for offset, extent, etc.

[Jdbye]

Describe your issue A panel implementing IScrollInfo is supposed to support logical scrolling when ScrollViewer.CanContentScroll is set to true (which is the default for controls inheriting from ItemsControl, including ListBox and ListView), but VirtualizingWrapPanel seems to make no effort to implement this. This is the entire purpose of IScrollInfo, which is mentioned in the page linked below (you can see other panels such as Grid or WrapPanel do not implement it, it is specifically only StackPanel and VirtualizingStackPanel, as well as some ribbon panels, which all support logical scrolling), so I was curious why VirtualizingWrapPanel implements it if it doesn't support logical scrolling.

It behaves like logical scrolling when page up/page down are used, but the values for ExtentWidth, ExtentHeight, Offset, etc. don't use logical units as would be expected.

See: https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo?view=windowsdesktop-8.0

Version Info Package Version: 2.0.6 .NET Version: 6.0 OS Version: Windows 11 Build 22631.3737

[sbaeumlisberger]

Logical scrolling is supported but if it is used depends on the ScrollUnit, see: https://learn.microsoft.com/de-de/dotnet/api/system.windows.controls.virtualizingpanel.scrollunit?view=windowsdesktop-8.0

---

From: Jdbye @.> Sent: Thursday, July 4, 2024 12:39:17 PM To: sbaeumlisberger/VirtualizingWrapPanel @.> Cc: Subscribed @.***> Subject: [sbaeumlisberger/VirtualizingWrapPanel] Doesn't implement IScrollInfo / logical scrolling properly? (Issue #60)

Describe your issue A panel implementing IScrollInfo is supposed to support logical scrolling when ScrollViewer.CanContentScroll is set to true (which is the default for controls inheriting from ItemsControl, including ListBox and ListView), but VirtualizingWrapPanel seems to make no effort to implement this. This is the entire purpose of IScrollInfo, which is mentioned in the page linked below (you can see other panels such as Grid or WrapPanel do not implement it, it is specifically only StackPanel and VirtualizingStackPanel, which both support logical scrolling), so I was curious why VirtualizingWrapPanel implements it if it doesn't support logical scrolling.

See: https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo?view=windowsdesktop-8.0

Version Info Package Version: 2.0.6 .NET Version: 6.0 OS Version: Windows 11 Build 22631.3737

— Reply to this email directly, view it on GitHubhttps://github.com/sbaeumlisberger/VirtualizingWrapPanel/issues/60, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANPCTLTFNZ7NXG2KKZ4EVEDZKUQ5LAVCNFSM6AAAAABKLI5MJ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM4TANJUGE3DIMA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Jdbye]

Logical scrolling is supported but if it is used depends on the ScrollUnit, see: https://learn.microsoft.com/de-de/dotnet/api/system.windows.controls.virtualizingpanel.scrollunit?view=windowsdesktop-8.0

It behaves like logical scrolling when page up/page down or mouse wheel are used, but the values for ExtentWidth, ExtentHeight, Offset, etc. don't use logical units as would be expected. This is what I was referring to. Also, SetVerticalOffset/SetHorizontalOffset don't use logical units either.

I only noticed this when a piece of code that uses SetVerticalOffset/SetHorizontalOffset didn't behave as expected. Otherwise, I've been happily using this thing for months.

[sbaeumlisberger]

Okay now I understand. I'll have a look at it.

[sbaeumlisberger]

I don't know where you got the information that extent, viewport and offset should be in logical units. The documentation clearly states:

A Double that represents, in device independent pixels, the horizontal size of the extent. This property has no default value.

https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo.extentwidth?view=windowsdesktop-8.0](https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo.extentwidth?view=windowsdesktop-8.0)

Is there any reason or benefit to changing this? It would require some big changes, so I'm only considering it if I have a good reason.

If you want to scroll to specific item consider to use the ScrollIntoView method (https://learn.microsoft.com/de-de/dotnet/api/system.windows.controls.listbox.scrollintoview?view=windowsdesktop-8.0)

If you need to scroll some logical amount the easiest would be to multiply your value by the size of the items. If it helps, I could make the GetAverageItemSize method of the VirtualizingWrapPanel public. The method returns the size of the items, or the average if items of different sizes are allowed.

[Jdbye]

I don't know where you got the information that extent, viewport and offset should be in logical units. The documentation clearly states:

A Double that represents, in device independent pixels, the horizontal size of the extent. This property has no default value.

https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo.extentwidth?view=windowsdesktop-8.0](https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo.extentwidth?view=windowsdesktop-8.0%5D(https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.primitives.iscrollinfo.extentwidth?view=windowsdesktop-8.0))

Is there any reason or benefit to changing this? It would require some big changes, so I'm only considering it if I have a good reason.

If you want to scroll to specific item consider to use the ScrollIntoView method (https://learn.microsoft.com/de-de/dotnet/api/system.windows.controls.listbox.scrollintoview?view=windowsdesktop-8.0)

If you need to scroll some logical amount the easiest would be to multiply your value by the size of the items. If it helps, I could make the GetAverageItemSize method of the VirtualizingWrapPanel public. The method returns the size of the items, or the average if items of different sizes are allowed.

This page: https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.scrollviewer.cancontentscroll?view=windowsdesktop-8.0#system-windows-controls-scrollviewer-cancontentscroll

"If CanContentScroll is true, the values of the ExtentHeight, ScrollableHeight, ViewportHeight, and VerticalOffset properties are number of items, instead of physical units"

[Jdbye]

It's not such an important feature, but it would be useful. For example, in my program, the contents of the listview can be resized/zoomed. This does not really behave nicely with WPF, the visible items have to be scrolled back into view after the layout updates, but this results in there being a noticeable delay between the content resizing, when the scroll view ends up on the "wrong" items, before the scroll position is updated by the code. And the code has to keep track of the scroll position of every listview (or in my case, every tab, since the listview is generated by a Tab Control ItemsSource). It also remembers the scroll position for each tab. It's never possible to get it to behave flawlessly, and doing this sort of thing in code often introduces bugs in edge cases where the scroll position ends up being wrong. There have been many times where that code resulted in visual bugs because the layout had not updated yet at the time the ExtentWidth/ExtentHeight etc was read by the code. If the scroll units were in number of images, this sort of thing should be much easier to do, and behave much better. The ExtentWidth/ExtentHeight etc. would be independent of the layout of the listview so the values could not get out of sync with the current state of the layout. I realize it would require a lot of changes so it's totally up to you.

[sbaeumlisberger]

Okay, as far as I understand, the most important aspect is maintaining the scroll position when resizing the elements. I will investigate this further and consider using logical units for these properties as this seems to be the correct way. But this would be a breaking change in the behaviour, so it will require a new mayor version and a proper evaluation. That's something that's going to take some time.