Windows: Fix drag mouse position for parented windows (bugfix)

[AlexCharlton]

The drag position was being reported corrected on unparented windows, but it could be completely off for parented windows, depending on the parent. Rather than relying on the cursor position as reported by OLE, this calls GetCursorPos instead.

[AlexCharlton]

Waiting for #249, which will conflict

[prokopyl]

Your comments in the code mention having to work around DPI virtualization, and that seems quite weird to me since our windows should be DPI-aware.

Can you provide an example which reproduces this issue? (I'm guessing it's probably with a specific host that isn't DPI-aware for some reason?)

[AlexCharlton]

I ran into this problem on Bitwig, which launches plugins from one or more isolated processes. I'm surmising that these processes aren't DPI aware and it's this parent that the OLE thread is attached to and which generates the drag points, hence the coordinate mismatch. This is conjecture, but it would explain why the passed-in points are not in the same reference frame as the points fetched by GetCursorPos.

Your comment made me realize that I really ought to test this on a host with a different way of handling plugins, and lo and behold, this solution does not hold water with Reaper. So, back to the drawing board. I'll keep this in draft until I figure out a solution that works more broadly.

[AlexCharlton]

Getting this working was more convoluted than I imagined, but I'll describe what I encountered, and how I wound up here.

There's two different issues being fixed.

First is the coordinates of the point being given by the OLE process. For non-parented windows, everything seemed kosher. For windows with parents, the results differ by host. In Reaper, the OLE point was as expected: After ScreenToClient, they have the correct reference frame and are in physical pixels. In Bitwig, they were shifted to some frame of reference that I can only guess at. For instance, at the top-left of my window I was getting 490x-383 after converting ScreenToClient. Using GetCursorPos to get the point addressed this issue.

Second, the scale of the point returned by GetCursorPos differs based on the combination of the parent AND the drag source. With Reaper as the parent, the GetCursorPos was reliably in physical pixels no matter the drag source. In Bitwig, a custom (baseview) drag source was resulting in physical pixels, while using Windows Explorer as a drag source resulted in logical pixels.

This made it necessary to detect whether the specific drag context would return physical or logical pixels, which I accomplished by calling GetClientRect and comparing the results to the dimensions held by the window state. GetClientRect returned a rect scaled in the same manor as GetCursorPos, so it either returns physical or logical pixels depending on the drag context. This result of this detection is cached on the DropTarget, so it only happens once per drag.

Why this is so damn hairy is beyond me, and if you have any other ideas, I'm all ears.