CursorBehavior doesn't work in some scenarios.

[DanTravison]

I found CursorBehavior isn't reliable if set programmatically.

In my case, I have a custom control that uses one of two cursors depending on its orientation and it is set programmatically versus via Xaml. In my control tests, it works reliably but, in the application, it fails.

Since I don't have control over how the control is instantiated, I decided to figure out a method for deferring the call to the platform code.

My first solution was to subscribe to the PlatformChanged in the attached property if the MauiContext is not yet available. Then, if the MauiContext is available at Set time, set it directly; otherwise, set it in the PlatformChanged handler.

This feels incomplete since it doesn't handle the case of MauiContext already being set nor the case where the platform changes (i.e., is the platform code leaking gestures/event handlers?)

So, I have some questions:
1: Is there a better method for handling this?
2: Should CursorBehavior handle this case versus throwing ArgumentNullException?
3: If there a leak in some of CursorBehavior's platform code if the handler changes or does WeakEventManager address this?

Thanks.

[DanTravison]

FWIW: I have a proof of concept that addresses the issues I'm seeing.

It's not as straight forward as I hoped but it does retain the slightly refactored platform code here.

It essentially splits the attached property into two, a public facing Cursor property and an internal PlatformCursor property. The later contains the platform specific code as a class instance to support deferring until IMauiContext is valid and releasing previous resources when the VisualElement's handler changes.

https://github.com/DanTravison/MauiCursor

[VladislavAntonyuk]

You can use https://github.com/CommunityToolkit/Maui/blob/main/src/CommunityToolkit.Maui/Behaviors/BaseBehavior.shared.cs
It should handle all your scenarios