Xnews was treating all mouseclicks as drag-and-drop operations in the newsgroup listview. The problem was that LISTVIEW_TrackMouse was losing the WM_LBUTTONUP message. This patch adds the missing call to DispatchMessage.
License: X11, LGPL Changelog: prupe@myrealbox.com Dispatch the last message when exiting LISTVIEW_TrackMouse
On Sun, 9 May 2004 21:05:04 -0400, you wrote:
Xnews was treating all mouseclicks as drag-and-drop operations in the newsgroup listview. The problem was that LISTVIEW_TrackMouse was losing the WM_LBUTTONUP message. This patch adds the missing call to DispatchMessage.
License: X11, LGPL Changelog: prupe@myrealbox.com Dispatch the last message when exiting LISTVIEW_TrackMouse
I have seen a similar problem with Newsbin.
The problem here is that on Windows the WM_LBUTTONUP message *is* swallowed when it terminates a drag and drop operation. The real problem is probably not to get in this LISTVIEW_TrackMouse in the first place.
Rein.
On Monday May 10 2004 07:31 am, Rein Klazes wrote:
The problem here is that on Windows the WM_LBUTTONUP message *is* swallowed when it terminates a drag and drop operation. The real problem is probably not to get in this LISTVIEW_TrackMouse in the first place.
I'm not sure I follow. If I understood the code right, when there is a real drag-and-drop event, we *do* swallow the WM_LBUTTONUP message like Windows does. That's the "ReleaseCapture(); return 1;" block which my patch doesn't affect. What I changed was the "never mind, the mouse button was pressed, but it wasn't a drag-and-drop after all" part. But I could certainly have missed something, can you explain further?
On Wed, 12 May 2004 09:07:25 -0400, you wrote:
On Monday May 10 2004 07:31 am, Rein Klazes wrote:
The problem here is that on Windows the WM_LBUTTONUP message *is* swallowed when it terminates a drag and drop operation. The real problem is probably not to get in this LISTVIEW_TrackMouse in the first place.
I'm not sure I follow. If I understood the code right, when there is a real drag-and-drop event, we *do* swallow the WM_LBUTTONUP message like Windows does. That's the "ReleaseCapture(); return 1;" block which my patch doesn't affect.
I do not think so: it is inside a "if (msg.message == WM_MOUSEMOVE)" block.
What I changed was the "never mind, the mouse button was pressed, but it wasn't a drag-and-drop after all" part. But I could certainly have missed something, can you explain further?
Drag&drop is normally ended releasing the mouse button : WM_LBUTTONUP message. Hence the break and it will be affected by your patch.
But I am only assuming that what I see here, is the same as what you see. If you run your program with native comctl32, do you see the message pump (the peekmessage's) in action? In my case I only see it with built-in comctl32.
Rein.