http://bugs.winehq.org/show_bug.cgi?id=31280
Bug #: 31280 Summary: Right-clicking a listview in a dotnet application doesn't open the context menu Product: Wine Version: 1.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: spacejock@gmail.com Classification: Unclassified
I have several dotnet 2.0 applications which I'm trying to run under Wine. (I have the source code, which makes testing easier.)
Each application has one or more listview controls on a form. Under Windows, right-clicking the listview brings up the associated context menu. Under wine, the right click doesn't register.
By that I mean the click event isn't even firing.
I added some code to test the right-click event on other areas of the form, and that works fine. Right-clicking on other controls (e.g. textboxes) works fine. The only issue is that right-clicking on a listview does nothing. If you double-right click an entry in the list, Wine acts as though you double left-clicked.
I've tested this with dotnet 2, dotnet 2SP1 and dotnet2 sp2 under Ubuntu Linux 12.04. I've tried under KDE and Unity/Gnome, just in case it was a WM problem. No difference.
http://bugs.winehq.org/show_bug.cgi?id=31280
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #1 from Dan Kegel dank@kegel.com 2012-07-22 09:21:13 CDT --- Does the problem also happen with wine-1.5.9 (which comes with mono) without .net installed?
Can you provide a trivial app with source and executable which exhibits the problem?
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #2 from Simon Haynes spacejock@gmail.com 2012-07-22 09:35:20 CDT --- (In reply to comment #1)
Does the problem also happen with wine-1.5.9 (which comes with mono) without .net installed?
Can you provide a trivial app with source and executable which exhibits the problem?
(In reply to comment #1)
Does the problem also happen with wine-1.5.9 (which comes with mono) without .net installed?
Can you provide a trivial app with source and executable which exhibits the problem?
Thanks for the quick reply.
I've been tinkering with my software for several years now, trying to get it working under Mono since Mono was at version 2.2. I believe they dropped winforms support recently, and that was the end of that.
I decided to try Wine again just this week, hence the bug report.
Note that if I use 'winetricks comctl32' to override the Wine native controls, right-click works fine, so the issue must be with the implementation of the listview control under Wine.
If I post source for a trivial VB.net project, can you compile and run it? (Not under Mono, under Visual Studio?)
I can make the project easily enough (listview on a form, add a context menu.) Before I do, now that I've used Winetricks to install the comctl32 dlls, I'd have to revert to the native dlls before testing the project.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #3 from Dan Kegel dank@kegel.com 2012-07-22 09:41:47 CDT --- A tiny VB.NET app would do nicely, but please zip up the entire project folder including compiled .exe so both people who can rebuild and those who can't are able to test.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #4 from Simon Haynes spacejock@gmail.com 2012-07-22 10:45:06 CDT --- (In reply to comment #3)
A tiny VB.NET app would do nicely, but please zip up the entire project folder including compiled .exe so both people who can rebuild and those who can't are able to test.
Okay, will do. I reverted to native comctl32 and the listview in my app failed to show the context menu (as expected)
However, the context menu on the simple test app did show.
The difference between the two is that my app has the listview nested inside a tabcontrol.
I will now modify the small test app so the nesting is the same.
(...)
I've modified the small app, and it still shows the context menu correctly. My app still doesn't show the context.
I've just copy/pasted the listview from my app into the test. Still works.
Copied the entire layout across - still works!
It's midnight here now so I'll continue testing tomorrow until I find out what the difference is between the two.
In the meantime, when I click an entry in the listview on my app, this is what the console shows. (This is all from one click on a non-focused listview. I'm including it in case there are any clues.)
fixme:wbemprox:wbemprox_cf_QueryInterface interface {b196b28f-bab4-101a-b69c-00aa00341d07} not implemented fixme:wbemprox:wbem_locator_QueryInterface interface {c3fcc19e-a970-11d2-8b5a-00a0c9b7c9c4} not implemented fixme:wbemprox:wbem_locator_QueryInterface interface {00000003-0000-0000-c000-000000000046} not implemented fixme:wbemprox:wbem_locator_QueryInterface interface {00000144-0000-0000-c000-000000000046} not implemented fixme:ole:Context_QueryInterface interface not implemented {51372ae0-cae7-11cf-be81-00aa00a2fa25} fixme:wbemprox:wbem_locator_ConnectServer 0x69c1730, L"\\.\root\cimv2", (null), (null), L"", 0x00000080, L"", (nil), 0x673d09c) fixme:wmiutils:wmiutils_cf_QueryInterface interface {b196b28f-bab4-101a-b69c-00aa00341d07} not implemented fixme:wmiutils:status_code_QueryInterface interface {c3fcc19e-a970-11d2-8b5a-00a0c9b7c9c4} not implemented fixme:wmiutils:status_code_QueryInterface interface {00000003-0000-0000-c000-000000000046} not implemented fixme:wmiutils:status_code_QueryInterface interface {00000144-0000-0000-c000-000000000046} not implemented fixme:wmiutils:status_code_GetErrorCodeText 0x69c10b8, 0x80041001, 0x0000, 0x00000001, 0x673d47c
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #5 from Dan Kegel dank@kegel.com 2012-07-22 10:51:56 CDT --- Sounds like divide-and-conquor is in order. Iterate like this: while (can stand it) { verify app still has problem. If not, revert previous change. remove half of app rebuild } and then once you have a small app that still exhibits the problem, either the bug or the fix or both will become clear.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #6 from Simon Haynes spacejock@gmail.com 2012-07-22 10:57:55 CDT --- (In reply to comment #5)
Sounds like divide-and-conquor is in order. Iterate like this: while (can stand it) { verify app still has problem. If not, revert previous change. remove half of app rebuild } and then once you have a small app that still exhibits the problem, either the bug or the fix or both will become clear.
The app is huge, with many forms and tens (hundreds?) of thousands of lines of code. Fortunately the error shows up on the main form.
My plan is to copy the main form only into another (empty) project, and comment out everything. Then I'll bring back bits and pieces until the right-click no longer works.
Once I find out what it is I'll make up a project which reliably shows the error, and I'll submit it here.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #7 from Simon Haynes spacejock@gmail.com 2012-07-23 00:12:07 CDT --- Created attachment 41121 --> http://bugs.winehq.org/attachment.cgi?id=41121 VB.net 2008 project (Pro or Express), plus compiled exe version
This zip file contains a VB2008 project file & associated source code. There is one form with a tab control containing listview controls on each tab.
The code behind the form creates one entry in one of the listviews.
In the Debug/bin folder there's a compile exe version of the project.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #8 from Simon Haynes spacejock@gmail.com 2012-07-23 00:13:38 CDT --- (In reply to comment #7)
Created attachment 41121 [details] VB.net 2008 project (Pro or Express), plus compiled exe version
This zip file contains a VB2008 project file & associated source code. There is one form with a tab control containing listview controls on each tab.
The code behind the form creates one entry in one of the listviews.
In the Debug/bin folder there's a compile exe version of the project.
Under wine, you can right-click the column headers and the context menu will appear. Right-click the body of the listview and it doesn't.
Under Windows, right-clicking the listview shows the context menu.
I had a look in WineDB and Microsoft's SyncToy 2.1 shows a comment about right-click menus not working properly in the file lists on the main screen, so I'm guessing this is a related bug. (SyncToy also requires dotnet 2.0)
Note that using winetricks comctl32 to override the builtin dll fixes the issue, and the context menu appears as expected.
http://bugs.winehq.org/show_bug.cgi?id=31280
Daniel Jelinski djelinski1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |djelinski1@gmail.com
--- Comment #9 from Daniel Jelinski djelinski1@gmail.com 2012-07-23 01:56:39 CDT --- Also affects MS SQL Server management studio 2005. That application refuses to work with native comctl, so there's no workaround.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #10 from Simon Haynes spacejock@gmail.com 2012-07-23 02:12:15 CDT --- (In reply to comment #9)
Also affects MS SQL Server management studio 2005. That application refuses to work with native comctl, so there's no workaround.
The reason I reported the bug is because it seems to affect all dotnet 2.0 applications.
If a simple test case like the one I uploaded can reveal the reason right-clicking won't work in Wine, and it can be fixed, then other programs should benefit.
During my testing I discovered that Wine does not detect a right-click on listview controls *at all*. The column headers (in detail view), yes. Rows of data or empty areas of the listview, no.
I set up a couple of tests, one to detect right-clicks on a regular form, and the other to detect right-clicks on listview. The first fired and the second didn't.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #11 from Daniel Jelinski djelinski1@gmail.com 2012-07-23 02:42:25 CDT --- A test case is great, but usually generic bugs without any specific applications tend to wait forever for someone to fix them. Consider adding this bug to appdb entries of applications you tested.
This bug is caused by incorrect messages sent on right click. Easy to see by comparing the output of "WINEDEBUG=+message wine WineTest.exe" with native comctl to the same output with builtin.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #12 from Simon Haynes spacejock@gmail.com 2012-07-23 02:49:12 CDT --- (In reply to comment #11)
A test case is great, but usually generic bugs without any specific applications tend to wait forever for someone to fix them. Consider adding this bug to appdb entries of applications you tested.
This bug is caused by incorrect messages sent on right click. Easy to see by comparing the output of "WINEDEBUG=+message wine WineTest.exe" with native comctl to the same output with builtin.
I'm the programmer behind yWriter (novel writing software), which has tens of thousands of users ... many of whom want to run it on Mac or Linux. (I have another two dozen programs which aren't used quite as heavily as this one, but the ones I've tested all show the same problem.)
Until now I've been telling people to run it on Mono, but winforms isn't up to the job any more. (There's a showstopper bug which has been there since Mono 2.4 and apparently isn't going to be fixed.)
Even the windb entry says they tried to run it by installing Mono under wine, instead of dotnet 20: http://appdb.winehq.org/objectManager.php?sClass=version&iId=22865&i...
Over the years I've been very careful not to use API calls, custom libraries or third party controls, or mssql, instead writing everything from scratch myself to make my software as easy to run on wine/mono as possible. I'm happy to test this thing into the ground if it'll fix the problem. Alternatively I can just tell users to run winetricks comctl32
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #13 from Dan Kegel dank@kegel.com 2012-07-23 09:31:51 CDT --- I've linked this bug to yWriter in appdb. If you know of other specific apps that suffer from this, you might log in to http://appdb.winehq.org and link them, too.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #14 from Vincent Povirk madewokherd@gmail.com 2012-07-23 09:35:23 CDT --- Could you make sure we have a wine bug for the mono/winforms issue? Maybe someone in the Wine community will care more about it.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #15 from Dan Kegel dank@kegel.com 2012-07-23 09:37:34 CDT --- Would it just be a dup of this bug, but in category mscoree?
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #16 from Simon Haynes spacejock@gmail.com 2012-07-23 19:33:13 CDT --- (In reply to comment #14)
Could you make sure we have a wine bug for the mono/winforms issue? Maybe someone in the Wine community will care more about it.
I reported the Mono bug on their system. You'll find the details right here along with my sample code that triggers the error:
https://bugzilla.xamarin.com/show_bug.cgi?id=5040
The effect of the bug is to cause an infinite loop in modal dialogs, which locks up any program affected.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #17 from Simon Haynes spacejock@gmail.com 2012-07-23 19:35:41 CDT --- (In reply to comment #16)
(In reply to comment #14)
Could you make sure we have a wine bug for the mono/winforms issue? Maybe someone in the Wine community will care more about it.
I reported the Mono bug on their system. You'll find the details right here along with my sample code that triggers the error:
https://bugzilla.xamarin.com/show_bug.cgi?id=5040
The effect of the bug is to cause an infinite loop in modal dialogs, which locks up any program affected.
(Also note my Comment 1 on the xamarin bug report page:
"I'm wondering whether setting DialogResult = Windows.Forms.DialogResult.OK is actually firing the FormClosing event?"
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #18 from Simon Haynes spacejock@gmail.com 2012-07-23 20:08:31 CDT --- (In reply to comment #17)
(In reply to comment #16)
(In reply to comment #14)
Could you make sure we have a wine bug for the mono/winforms issue? Maybe someone in the Wine community will care more about it.
I reported the Mono bug on their system. You'll find the details right here along with my sample code that triggers the error:
https://bugzilla.xamarin.com/show_bug.cgi?id=5040
The effect of the bug is to cause an infinite loop in modal dialogs, which locks up any program affected.
(Also note my Comment 1 on the xamarin bug report page:
"I'm wondering whether setting DialogResult = Windows.Forms.DialogResult.OK is actually firing the FormClosing event?"
Okay, this is off-topic for the bug I'm reporting here, but I just inspected the source for Mono 2.10.9 and found this comment in the source for DialogResult in Form.cs:
if (dialog_result != DialogResult.None && is_modal) RaiseCloseEvents (false, false); // .Net doesn't send WM_CLOSE here. }
I'm guessing that's the issue in Mono, and the reason the behaviour is different.
http://bugs.winehq.org/show_bug.cgi?id=31280
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source Component|-unknown |comctl32
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #19 from Daniel Jelinski djelinski1@gmail.com 2013-01-27 08:13:13 CST --- The reason behind this bug is that dotnet subclass of listview does not forward WM_RBUTTONUP message to listview. Native listview captures the message queue (i.e. starts calling GetMessage, and calls DispatchMessage only on selected messages) as soon as it receives WM_RBUTTONDOWN, and releases it after either WM_RBUTTONUP or WM_MOUSEMOVE if mouse cursor moved at least 4 pixels away. We have already implemented a similar mechanism for treeview (see TREEVIEW_TrackMouse). Correct fix for this should also fix bug 13417.
http://bugs.winehq.org/show_bug.cgi?id=31280
--- Comment #20 from Daniel Jelinski djelinski1@gmail.com 2013-01-28 14:54:58 CST --- Fixed by 500da7def68934d2e2d74e611bb6cce77d59d60e, tested in SQL management studio.
http://bugs.winehq.org/show_bug.cgi?id=31280
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |500da7def68934d2e2d74e611bb | |6cce77d59d60e Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #21 from Nikolay Sivov bunglehead@gmail.com 2013-01-28 15:07:07 CST --- Fixed.
http://bugs.winehq.org/show_bug.cgi?id=31280
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:01 CST --- Closing bugs fixed in 1.5.23.