Window.DragMove() sucks

[Jeremiah Morrill]

For those that follow me on twitter, you may have found out that I have recently blacklisted Window.DragMove().

The problem is it uses some WPF unfriendly Win32 calls that will block your UI thread if you just click and do not move the mouse button.  This is just enough to be annoying as hell if you happen to have any animations/video running at that moment.  I whipped up a simple Blendhavior to act as a replacement for DragMove.

Please don't use DragMove again.

Ya'll been warned.

-Jer

[Eric Burke]

Since WPF Input runs at a lower priority than other stuff (Render, Loaded, DataBind, Normal, Send), if you have a lot going on at higher priority, how does that affect the drag operation in terms of lagging the mouse?   The Win32 APIs probably use lower-level mouse operations which are closer to the metal, at the expense of blocking the UI thread.

---

From: Jeremiah Morrill <jeremiah...@gmail.com>
To: wpf-di...@googlegroups.com
Sent: Friday, July 31, 2009 5:06:58 PM
Subject: [WPF Disciples] Window.DragMove() sucks

[Jeremiah Morrill]

I'm going to speculate based on the symptoms...

I think the internal Win32 SendMessage(SC_MOVE + HTCAPTION) does a block the the UI thread (with a 1 second timeout) while it asyncronously listens for mouse move messages.  As soon as it gets a mouse move message, the block is lifted an the window will move.  Possibly this is why when you just click the mouse w/o moving it, it will freeze momentarily, but if you click then drag all is well and there is no block.

-Jer