http://bugs.winehq.org/show_bug.cgi?id=25082
Summary: radmin: right mouse key drag'n'drop not working Product: Wine Version: 1.3.6 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: emoxam@gmail.com
in radmin client 3.4 it's easy to copy connection just with drag'n'drop by a right mouse keys, but in wine right mouse key works so as you do not move the cursor, like you pressed and released the right mouse button in one time. so where you released the key - there it is working - on a connection - that will be connection property, in a list - options of listiong connection.
Ubuntu 10.4 Linux.
http://bugs.winehq.org/show_bug.cgi?id=25082
Daniel Jelinski djelinski1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |djelinski1@gmail.com
--- Comment #1 from Daniel Jelinski djelinski1@gmail.com 2013-01-26 16:03:22 CST --- radmin uses listview for list of connections. LVN_BEGINRDRAG notification is still not implemented, therefore - still an issue in current wine.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com 2013-01-26 16:12:01 CST --- So you're saying this works with native comctl32? LVN_BEGINDRAG is actually implemented in wine by the way.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #3 from Daniel Jelinski djelinski1@gmail.com 2013-01-26 16:23:57 CST --- LVN_BEGIN_R_DRAG (the one for right mouse button) is not. It's my educated guess that it's the reason here - I have not tested the application, just googled its screenshots.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com 2013-01-27 02:59:44 CST --- Created attachment 43354 --> http://bugs.winehq.org/attachment.cgi?id=43354 patch
Yeah, sorry I misread. I attached a possible fix for that.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #5 from Alexander emoxam@gmail.com 2013-01-27 05:23:46 CST --- pardon, and what should i do with that patch ?
http://bugs.winehq.org/show_bug.cgi?id=25082
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |comctl32 Ever Confirmed|0 |1 Severity|normal |minor
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2013-01-27 07:20:20 CST --- (In reply to comment #5)
pardon, and what should i do with that patch ?
If you want to test it you'll need to fetch wine-git repo, apply a patch and build a tree. To do that you need build environment for your system and all needed dependencies that wine links to.
I actually tried it myself just now and it fixes a problem. With this patch I get a popup menu with Copy/Move/Cancel when I drag connection icon with a right button, reverting a patch breaks it as you described. I'll send a patch tomorrow and it should be included in next wine release, you'll be notified.
P.S. Daniel, thanks for analysis.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #7 from Daniel Jelinski djelinski1@gmail.com 2013-01-27 07:28:50 CST --- No problem. I also tested the application, and there is still a minor glitch here: - right-drag connection - Copy/Move menu appears; select anything from that menu - right-drag connection again - this time when you release right MB, standard context menu appears - right-drag again - Copy/Move menu appears again. It looks like ListView does not reset its state after dragging.
With native comctl from winetricks dragging works every time.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com 2013-01-27 11:19:01 CST --- Yes, I think it's something to do with pointer capture. Could be related to message processing difference you pointed in bug 9932.
http://bugs.winehq.org/show_bug.cgi?id=25082
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #43354|0 |1 is obsolete| |
--- Comment #9 from Nikolay Sivov bunglehead@gmail.com 2013-01-27 11:46:42 CST --- Created attachment 43362 --> http://bugs.winehq.org/attachment.cgi?id=43362 patch
This one uses loop like TreeView does, and it helps here for a problem you described with my previous patch. Could you confirm?
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #10 from Daniel Jelinski djelinski1@gmail.com 2013-01-27 14:35:07 CST --- Ack, works for me, also fixes bug 13417. You should also see what notify_click returns. It's quite unexpected :) For some reason, even with notify_click fixed, bug 31280 is still present. I'll try to figure that out.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #11 from Daniel Jelinski djelinski1@gmail.com 2013-01-27 14:47:57 CST --- Got it. Unlike treeview, listview sends WM_CONTEXTMENU to itself, not to parent. After changing that (and notify_click), bug 31280 is fixed as well.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com 2013-01-27 21:36:49 CST --- (In reply to comment #11)
Got it. Unlike treeview, listview sends WM_CONTEXTMENU to itself, not to parent. After changing that (and notify_click), bug 31280 is fixed as well.
Yeah, it's copy/paste problems from treeview code, NM_RCLICK return value should be reversed and WM_CONTEXTMENU should be sent to self. I'll send fixed version, thanks!
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #13 from Daniel Jelinski djelinski1@gmail.com 2013-01-27 23:43:10 CST --- Well, this should also work for these bugs. In order to be correct the code would have to take return value from NM_RCLICK into account. notify_click returns an information if the listview window still exists.
That return value is a huge pain. It was introduced by commit c0b79e0b055a0093ab1c2c129c593d74e51d3709, which was a hack intended to fix bug 3366, which was most likely a bug in comdlg. That hack is most likely not needed by any other application. Now there are multiple notify functions, and some return the result of SendMessage, others return the result of IsWindow, and you have to check each time. Do you think we could get rid of that IsWindow mess?
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com 2013-01-27 23:55:24 CST --- (In reply to comment #13)
Well, this should also work for these bugs. In order to be correct the code would have to take return value from NM_RCLICK into account. notify_click returns an information if the listview window still exists.
Yes, NM_RCLICK seems to be special case here, cause other notification don't care about return value, well according to MSDN at least. It should be fixed separately with another patch.
That return value is a huge pain. It was introduced by commit c0b79e0b055a0093ab1c2c129c593d74e51d3709, which was a hack intended to fix bug 3366, which was most likely a bug in comdlg. That hack is most likely not needed by any other application. Now there are multiple notify functions, and some return the result of SendMessage, others return the result of IsWindow, and you have to check each time. Do you think we could get rid of that IsWindow mess?
Well, to be sure it will need some test application for interactive testing. For example if native reliably crashes if control is destroyed during NM_CLICK and others we could remove that stuff.
http://bugs.winehq.org/show_bug.cgi?id=25082
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |500da7def68934d2e2d74e611bb | |6cce77d59d60e Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #15 from Nikolay Sivov bunglehead@gmail.com 2013-01-28 15:08:18 CST --- Fixed with 500da7def68934d2e2d74e611bb6cce77d59d60e. I'm working on NM_RCLICK part at the moment.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #16 from Daniel Jelinski djelinski1@gmail.com 2013-01-28 15:29:54 CST --- Thank you! Much appreciated. Could you also take a look at bug 9932? Fix for that should be quite similar to this one.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #17 from Nikolay Sivov bunglehead@gmail.com 2013-01-28 15:48:05 CST --- Sure, I'll take a look tomorrow. Actually this still doesn't work exactly as it should regarding right button (not related to this bug): if you press right button and keep it down and then click left button you get NM_RCLICK while wine fires NM_CLICK. Testing shows however that it breaks from a loop in this case at least - you can't drag after clicking left button while right is pressed, that's a relief. I'll see what I can do.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #18 from Daniel Jelinski djelinski1@gmail.com 2013-01-28 23:39:06 CST --- You mean this sequence: R-down, L-down, L-up, R-up? Actually it fires both NM_RCLICK (in response to WM_LBUTTONDOWN) and NM_CLICK (in response to WM_LBUTTONUP). When you remove WM_LBUTTONUP handler, it will behave correctly.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #19 from Nikolay Sivov bunglehead@gmail.com 2013-01-28 23:57:15 CST --- With ControlSpy I'm using it doesn't. If I keep right button down and click left repeatedly all I get is NM_RCLICK. When reversed, with left button down and clicking right I still get only NM_RCLICK.
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #20 from Alexander emoxam@gmail.com 2013-01-29 00:30:17 CST --- i don't think that you should fix that case behavior. Left mouse key drag'n'drop works ? Good, no need to think about pressing right key when left key is pressed. Who will press mouse buttons so ? :)
http://bugs.winehq.org/show_bug.cgi?id=25082
--- Comment #21 from Nikolay Sivov bunglehead@gmail.com 2013-01-29 00:41:19 CST --- (In reply to comment #20)
i don't think that you should fix that case behavior. Left mouse key drag'n'drop works ? Good, no need to think about pressing right key when left key is pressed. Who will press mouse buttons so ? :)
The point is to match behaviour, correct message processing is important. But yeah, this case is minor and we probably could live without it for now.
http://bugs.winehq.org/show_bug.cgi?id=25082
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.radmin.com/downl | |oad/radmin35.zip
http://bugs.winehq.org/show_bug.cgi?id=25082
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2013-02-01 04:56:15 CST --- Closing bugs fixed in 1.5.23.
-
wine-bugs＠winehq.org