[smittie2000]

handle_os_dragging posted WM_NCLBUTTONDOWN with &points as *const _ as LPARAM,
which passes the address of the POINTS struct rather than the coordinates.
Windows reads the coordinates from the bits of lParam itself (low word x, high
word y, each a signed 16-bit value, as decoded by GET_X_LPARAM/GET_Y_LPARAM).

This packs the cursor position into lParam directly. Each coordinate is
truncated to u16 first, so negative positions on multi-monitor setups survive
the round trip. This affects both Window::drag_window and
Window::drag_resize_window.

Tested on Windows 10 x64: inspecting the posted message for a move and a
south-east resize shows the wrong coordinates before this change and the correct
ones after.

See WM_NCLBUTTONDOWN.

v0.30.x still posts the address of POINTS here. I'm happy to open a backport if that's wanted.

[ogoffart]

Looks sensible.
Have you considered using transmute to convert from POINT to LPARAM?

[smittie2000]

I did not think of that.
I am assuming you meant POINTS as POINT holds two 32bit value so transmute to LPARAM will put y in the wrong place for 64bit systems and not compile on 32bit system

Let me know if i change it. Something in the lines of

let position = unsafe { mem::transmute::<POINTS, u32>(points) } as LPARAM;

[smittie2000]

@ogoffart I'd prefer to keep the explicit packing since it avoids unsafe and doesn't rely on POINTS's layout, but happy to switch to transmute if you prefer.

[smittie2000]

Closing in favour of #4825, which now includes this commit unchanged. Both fixes edit the same PostMessageW call in handle_os_dragging, so a single tested PR avoids the merge conflict between them.

@ogoffart thanks for the review. I kept the explicit packing there rather than transmute.