Adjust DragWindow cursor position fetch to avoid compounding dpi mult…

[Acissathar]

PR Details

When dragging and dropping an element from a UI library, the tooltip is offset greatly from the cursor. While the actual functionality seems fine and related to the cursor (e.g. positioning of element), it is an odd disconnect visually.

This appears to be due to a compounding DPI multiplication issue with the current WPF handling for the drag and drop. The old code mixed PointFromScreen (client-area-relative DIPs) and then added in Left/Top (outer-frame position), which produced an offset equal to the window's non-client area.

A DPI ratio was then applied on top of this, but because it was already slightly incorrect (inner frame vs outer frame), it would be compounded at non-100% DPI as seen here:

OnGiveFeedback now calls DragWindow.GetCursorRelativePosition() and applies the result as an incremental update, so that all math stays in DragWindow's own logical coordinate space, so WPF then (should) handle the DPI scaling itself.

DoDragDrop also now sets the initial window position before Show to help prevent the window showing for a frame at the default window position. Honestly since this is a single frame its probably not even noticeable, but I figured it didn't hurt to at least do it for consistency.

Now it remains by the cursor as expected:

Lastly, also included in this fix (which can be spun out to its own issue if desired, but it was super minor and in the same file so I snuck it in) is that the Drag and Drop box was initializing as inactive (generally correct) but not showing any text to state that until you moved it over a new area.

Previous:

Now:

Related Issue

#3106

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

[Acissathar]

@Kryptos-FR This minor tweak works for me locally, but given it seems to be a WPF issue (and again it functionally still works, so not really a blocking bug) and the editor rewrite is in process, I'm not sure how valuable / useful this is. It could also just be my monitor's scaling as you mentioned for what its worth, so figured I'd throw it up as a draft.

[Ethereal77]

Imho even if the editor rewrite in Avalonia is in progress, every fix and feature that removes friction from the editor and lessens the frustration of users merits being merged. Also, while the editor rewrite is finished, what we have is the WPF editor.