[Windows] Changes in SwipeViewHandler #11229
Conversation
jsuarezruiz
added
t/bug
Eilon
added
the
legacy-area-controls
|
|
||
| namespace Microsoft.Maui.Handlers | ||
| { | ||
| public partial class SwipeViewHandler : ViewHandler<ISwipeView, WSwipeControl> | ||
| public partial class SwipeViewHandler : ViewHandler<ISwipeView, MauiSwipeView> |
There was a problem hiding this comment.
We can't change the type on the SwipeViewHandler
We'll need to figure out the strategy here for changing these types.
Most likely we'll need to create a new handler and obsolete this one.
There was a problem hiding this comment.
We can't in .NET 7 but we can do it for .NET 8, right?
There was a problem hiding this comment.
Would it be possible to offer a variation via CommunityToolkit.Maui? Waiting another year for a bug fix is a problem...
|
The PR require some changes in the public API. Will maintain the changes up to date but need to wait to .NET 8. |
|
Will this be part of .NET 8? Should we complete it from the Draft to PR for review? |
|
Is this fixed in .NET 8 preview 5? I need this functionality in Windows, but before I go through the process up installing I'd like to make sure. |
No. You can check release notes https://github.com/dotnet/maui/releases/tag/8.0.0-preview.5.8529. But this PR is a draft. It's not finished - ie it's not even in the |
|
The .NET MAUI SwipeView control makes use of the SwipeControl https://learn.microsoft.com/en-us/windows/winui/api/microsoft.ui.xaml.controls.swipecontrol?view=winui-2.8 It is the most logical mapping although it is not 1:1 equivalent. Among the differences:
In addition to a reproducible crash when scrolling recycling views, are the reasons that made us explore the idea of using a custom control with its own implementation, just like it happens on other platforms. However, we are facing an important breaking change that is not going to replace the current implementation. The SwipeControl will not have mouse support, and the WinUI team recommends other types of interactions (contextual menus etc) using mouse etc. We are going to close this PR focusing on fix crashes or any problem that prevents the use of SwipeView in Windows while we continue to promote the implementations and accessibility on the desktop (keyboard support etc). |
Eilon
removed
the
legacy-area-controls
Description of Change
Updated SwipeViewHandler to use a custom control.
On Windows we used the SwipeControl control. It already had several limitations such as not allowing the use of the mouse, being able to open the SwipeControl programmatically, etc. We also accumulate certain errors in Windows mainly when scrolling. The control throws internal Win32 exceptions on initialization or when dynamically adding SwipeItems.
In order to have full control over the control used by completing pending implementations, align behaviors across all platforms, avoid some issues etc, we changed the used control to a custom control.
No differences with basic usage but now, is working using the mouse too.
But we can get complex scenarios using SwipeItemView with custom views working on Windows.
And also, in Windows there is functionality that did not work until now like for example, programmatically open the SwipeView.
Draft PR, do not merge (for now). There are some pending changes and also need to pass all the tests and validate every sample (basic usages, events, methods, etc). The PR is already open because it impacts a high percentage of issues related to SwipeView and to share that we are working on it.
Issues Fixed
Fixes #6152
Fixes #7757
Fixes #8327
Fixes #8328
Fixes #8870
Fixes #9233