I've been working on some drag and drop functionality based off of the Inventory sample, and its going well so far, but I have some doubts about how best to handle cursor changes.

From what I understand, the callback registered via SetCursorCallback is generally invoked when the mouse moves between elements with different FrameworkElement.Cursor values.

During a DoDragDrop, I assume it would be a bad idea to set FrameworkElement.Cursor (for the attached-to element or root view element) in the GiveFeedback handler, as even if it is restored afterwards, there could be some edge cases relating to inherited vs. local cursors, etc.

It then seems that the cursor callback would need to be side stepped here, calling directly into the underlying manager (e.g. SDL_SetCursor) instead. The previous cursor would probably have to be restored manually afterwards as well, and I'm not sure its enough to just revert to the FrameworkElement.Cursor value of the attached-to element.

Is my understanding correct?

I think it's better if the required cursor is updated using the FrameworkElement.Cursor. You can use the DragEnter/DragLeave events to update it accordingly, if your goal is to change the cursor depending on what elements are hovered during a drag-and-drop operation.

Did you find any problems with that approach?

The goal is mainly to select a cursor based on GiveFeedbackEventArgs.effects.

Setting FrameworkElement.Cursor seems to work if done on the root content element, e.g. The cursor is cleared again after DoDragDrop, which is fine until you have an explicit default Cursor value for the root content element, which cannot be restored easily from within the DragDropCompletedCallback, since the clearing happens afterwards, this is not really a big issue for me, but its probably worth mentioning anyways.

Also, the initial GiveFeedbackEventArgs.effects value reflects the "allowed drag effects", which makes it difficult to select the "No" (not allowed) cursor when the mouse is not over a valid drop target. This case does seem to be handled correctly when GiveFeedbackEventArgs.useDefaultCursors == true though. I expected the value to always reflect DragDropEffects_None, unless explicitly set by the drop target during its DragOver handler, though I'm not sure what standard WPF says about this.

Yes, the element that receives all the mouse events is the View root content element while the Drag and Drop operation is happening.

Regarding the clearing of the cursor after the drag completed callback, that seems like a bug. If you set args.useDefaultCursors = false it shouldn't modify the cursors for you, and you should be responsible of changing and restoring any cursor. Could you please report this in our bugtracker?

And in the GiveFeedback event you will receive the Effects you set when handling the DragEnter, DragOver and DragLeave events, so you can react accordingly to update the Cursor. This is the WPF behavior that Noesis is following.

Thanks, I made a bug report here: https://www.noesisengine.com/bugs/view.php?id=5087.

Regarding GiveFeedbackEventArgs.effects - when DragOver and friends are raised, the effects propagate as I expect.
But what is the expected value when a drop target has not yet been dragged over?

GiveFeedback is raised continuously, even when there is no UIElement with AllowDrop="True", and in this scenario, it seems to report the initial effects passed to DoDragDrop.
I'm just wondering how detect if there is a valid drop target within the GiveFeedback handler? I was hoping something like would be enough, but it seems I may need to track drop targets manually, probably by subscribing to PreviewDrag(Enter/Leave) events on the root element?

When a UIElement doesn't have the AllowDrop="True", the GiveFeedback event should report Effects=None.
So this seems like another bug, could you please report it too?

In the meantime the workaround could be having some root element with AllowDrop="True" that reports Effects=None in the DragOver handler.
Could you try that?

The workaround works until the mouse leaves the view bounds, then it falls back to the allowed effects (not a big issue for me, but worth mentioning).
Also, it only behaves if DragOverEventArgs.handled is set to true , otherwise it seems to override with DragDropEffects_Move internally, regardless of allowed effects, etc. (probably expected behaviour, but maybe also worth mentioning).

I'll make another bug report, but the default cursors work well enough for now, thanks!

Yes, e.handled must be set to true if you override the cursor and don't want Noesis code to use system cursors.

Thanks a lot for the tickets, we will fix those issues soon.