Community
Participate
Working Groups
There is a frequent and quite annoying problem with the current milestone of eclipse 3.1 (although it first happened with M3). It seems to occur randomly. Basically, when I am running the java editor the cursor stays as the IBeam icon (the one when you hover over text editors) no matter where I place my mouse over the eclipse window. It also exhibits the following behaviour: - When I click on anywhere in the eclipse window it changes the position of the cursor within the editor but does not click on what I want (for example if I click on the package explorer it will change the position of the blinking IBeam cursor in the editor to be inline of where I clicked but not on select the package I am clicking on). - I cannot click on any of the menus, views or buttons and cannot use any shortcut buttons to access the menus (like ALT+F to the "File" menu). - I cannot use the arrow keys, or HOME, END, PGUP etc to navigate within the editor. The only way I cam seem to do this is by clicking and using drag selection. - When I press CTRL+F6 to access the editors it will allow me to select an editor but I have to press ENTER to activate it - So basically the UI becomes unusable. My operating system is Windows XP SP2 I am running eclipse 3.1 milestone 4 with the following plugins installed: - EMF SDK 2.0.1 - GEF 3.0.1
Passing to SWT for comment
Few more comments: - The problems listed are only those which I have discovered there may be more - When I switch to other applications within Windows these work fine. - exiting eclipse and restarting has no effect. The only way it seems I can get around it is to reboot my machine.
I've only ever seen this happen when a program leaks badly. If that's the case, the there's nothing SWT can do. Does it happen every time or after you have run for a while? Is there a sequence of steps that make it happen?
I havn't noted any specific sequence of steps. It doesn't seem to be related to the amount of time I run eclipse because sometimes it happens very quickly after loading. I am developing eclipse plugins at the moment though, could it be a leak in my plugin causing the problem with the workbench it launched from?
Yes. Plugins run in the same address space as Eclipse and therefore use the operating system resource pool for the process.
I have the same problem (but I'm running eclipse 3.0.1). In additon: - using mouse scroll in the text editor can have something to do with the problem (I'm not sure, but clicking in the java editor and them moving the scroll up and down few times causes my mouse behave the way described above). - when the situation takes place the mouse stops working on any java application that is currently run on my machine. I can for example go to application's menu and it changes the way it does when the mouse is over it, but clicking has no results. From what I see I can "break" my mouse only starting from java editor in eclipse.
This problem is also described here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=49246#c7
The problem is fixed for me. I had an a4tech ps2 mouse which turned out to be be broken. After replacing the mouse with the new one everything is fine now. I've also performed some tests on my friend's machine - after installing my (broken) mouse he had the same symptoms in his eclipse (this includes both mouse and keyboard behaviour). After some time other (including non java) apps started to behave strange as my mouse dies. I hope this will also solve Graeme's problem.
Graeme, could it be a broken mouse?
Well I would hope it wouldn't be a broken mouse as it is my laptops touch pad! But this scenario doesn't really make sense to me anyway because as I said before all other applications carry on functioning normally including java applications (I use jEdit alot for quick text editing).
Just read through bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=49246#c7 This is exactly the same problem I am having now, although it is marked as fixed though this doesn't seem to be the case for me running the latest 3.1 milestone. I will try it with the -vmargs Mr Daniel Megert suggested as I am not setting any at the moment, but surely eclipse should warn or recommend that these be set up default?
I agree but Eclipse runs on different VM's and these arguments are not standard. I tried to get something done about this for 3.0 but failed.
I was experiencing the exact problems as in https://bugs.eclipse.org/bugs/show_bug.cgi?id=49246#c7 until I reverted back to the last versions of Java (1.4.0) and Eclipse (2.1.3) that had worked for me. I had made a post about this back in September in one Sun's forums because I felt it was a problem with Java, not Eclipse. I was experiencing the same issues with Sun's Java IDE and in other applications that used Java after moving to the latest version at the time (1.4.2_04?). The thread posted at Sun can be found at http://swforum.sun.com/jive/thread.jspa? forumID=78&threadID=48531.
Yesterday checked this with sun's java 1.4.0 (excluding eclipse 3.0.1), 1.4.1, 1.4.2 and 1.5 and bare eclipse 3.0.1 and 2.1.2. The sympthoms were present and the same for all those environments.
Graeme, did setting the vmargs (as suggested by Daniel in bug 49246) fix the problem for you? Daniel, Does this look like the same problem as bug 49246? Bug 49246 is marked as fixed, can you comment on what change was made to fix it?
I assumed that bug 49246 was caused by bug 50165 and marked it as fixed. I didn't mark it as duplicate since I wasn't 100% sure. It's not clear whether there were errors in the .log or not.
I am experiencing the same problem. I have been using the same build (I20041216-2000) for a while with no problem until recently. I upgraded to 3.1RC3 to see if it fixed it, but I have the same problem. I tried to up the max heap with -vmargs -Xmx512m with no success. I switched mouse with no success. I am running WinXP SP2. No log file is created Is there any way to make the log more verbose. I can recreate the problem starting from an empty workspace, new 3.1RC3 install. I just create a new java project, add one java class. As soon as I click inside the java editor the mouse focus is stuck in the editor. the cursor still moves, but remains the I-beam and clicks anywhere in eclipse behave like if the editor window extended to cover the whole eclipse window (they move the current selection point even when clicking out of the editor). Clicking on any application other than eclipse fixes everything until the next click in the editor. Same with Alt-Tab.
>>I agree but Eclipse runs on different VM's and these arguments >>are not standard. I tried to get something done about this for >>3.0 but failed. This got fixed for 3.1. By default, Eclipse increases the memory size so you don't need to specify -Xmx????? any more.
Vincent, does rebooting fix the problem?
(In reply to comment #19) > Vincent, does rebooting fix the problem? Rebooting does temporarily fix the problem. But as I noted, once the problem starts, restarting eclipse does not help and then, even the smallest possible workspace (1 project, 1 java class) has the problem. Let me know if there is any additional data that I could get you to help fix the problem.
1) Do you have any accessibility tools running? 2) Does a stand alone SWT application have the problem? Do either the ControlExample and CustomControlExample have the problem?
(In reply to comment #21) > 1) Do you have any accessibility tools running? No > 2) Does a stand alone SWT application have the problem? Do either the > ControlExample and CustomControlExample have the problem? I don't know. Eclipse is the only SWT app that I run. Where can i find the example apps that you mention.
I also have this problem as described in bug 49426 - with Eclipse 3.1.0 build I20050513 on XP pro sp2 with JDK 1.4.2_08. The mouse works fine with all other windows including some simple Java apps.
>I had an a4tech ps2 mouse which turned out to be be broken Since this doesn't HAPPENFORME, I have nothing to debug. Let's try to solve this thing remotely. 1) Gordon, could it be a broken mouse? 2) CAR, can you help these guys run the ControlExample to see whether the problem is in SWT or in Eclipse's use of SWT? BB, any ideas?
This problem doesn't occur with 3.0.1 Build id: 200409161125. With 3.1.0 it started as an intermittant problem that gradually got worse. Now continuous and reboot doesn't fix. It occurs with different mice and different USB sockets. If I run 3.0 and 3.1 at the same time with the same mouse the 3.0 version works and the 3.1 doesn't. Other people here have had the intermittant version. Does this only occur with Windows XP? Where do I get swtexamples.jar?
To run the ControlExample and CustomControlExample standalone: 1) Go to the download page for the eclipse version you already have. For example, for eclipse 3.1.0, this is: http://download.eclipse.org/downloads/drops/R-3.1-200506271435/index.php (Note that these instructions won't work for any eclipse prior to 3.1M7) 2) Scroll down a little bit until you see "Example Plug-ins" section. Download the examples zip for your platform, and unzip it to the same place that you originally unzipped eclipse. For example, for Windows, the example zip is: http://fullmoon.ottawa.ibm.com/eclipse/downloads/drops/R-3.1- 200506271435/download.php?dropFile=eclipse-examples-3.1-win32.zip and I personally unzip both eclipse and its examples to d:\ (Just say Yes when it asks if you want to overwrite the license files). So for the remaining steps, I will assume that you have eclipse and the eclipse examples both installed in d:\eclipse. I will also assume that you have a java jre in D:\jdk1.4.2_06\jre. 3) Open the file d:\eclipse\plugins\org.eclipse.swt.win32.win32.x86_3.1.0.jar in winzip, and extract the following 3 files into d:\eclipse\plugins - swt-awt-win32-3138.dll - swt-gdip-win32-3138.dll - swt-win32-3138.dll 3a) [optional, but recommended on Windows XP] You can also extract the file javaw.exe.manifest into your D:\jdk1.4.2_06\jre\bin directory. This will ensure that javaw.exe (and therefore, SWT) uses the Windows XP controls (instead of the Windows 2000 controls, which are the default in WinXP). 4) Open a DOS window and type: d: cd d:\eclipse\plugins\org.eclipse.swt.examples_3.1.0 5) Type the following line (note that this line is very long and Bugzilla has split it across 4 lines, but you should be able to just copy/paste it): D:\jdk1.4.2_06\jre\bin\java - classpath .;..\org.eclipse.swt_3.1.0.jar;..\org.eclipse.swt.win32.win32.x86_3.1 .0.jar;.\swtexamples.jar -Djava.library.path=.. org.eclipse.swt.examples.controlexample.ControlExample This is the ControlExample. There is a tab for each control, and you can change the various styles, etc, to see what changes in the controls. To run the CustomControlExample simply use the class name CustomControlExample instead of ControlExample in step 5. For the purpose of this bug, however, maybe the JavaViewer example is a better test, because the eclipse Java editor is implemented in a similar way, using the same (StyledText) control. To run JavaViewer, copy/paste the following [long] line into your DOS window: D:\jdk1.4.2_06\jre\bin\java - classpath .;..\org.eclipse.swt_3.1.0.jar;..\org.eclipse.swt.win32.win32.x86_3.1 .0.jar;.\swtexamples.jar -Djava.library.path=.. org.eclipse.swt.examples.javaviewer.JavaViewer Hope this helps.
Oops - you can't just copy/paste the split-up lines (worked in the Bugzilla editor - but I tried it after committing the comment, and I see that Bugzilla put hard returns in) so you'll have to paste it into Notepad and take out the returns before pasting into your DOS window. Good luck.
I ran ControlExample and CustomControlExample and also JavaViewer (without the java.exe.manifest change). There were no problems. So, I started Eclipse 3.1.0 and guess what? Also no problems. When the problem comes back I will try the examples again and let you know.
Problem re-occured in Eclipse and I can confirm that when present it also effects JavaViewer. JavaViewer has this behaviour 1) cursor keys don't work - up, down, left, right, home, end page- page up/down 2) after clicking inside the window, the window is no longer resizable and the scroll dar doesn't work - click on the scroll bar just moves the carot inside the window 3) switching the focus to another window seems to reset the problem. The keyboard, scroll bars and window resizing work but clicking inside the window "locks" the cursor again. When I opened Eclipse 3.0.1 the problem went away. Eclipse 3.1.0 and JavaViewer started to work again.
Do you have a set of steps you can do to make JavaViewer fail? That would help imensly.
This is a long shot, but are you running some other strange program? Say, a fancy desktop emulator or a strange configuration management tool, or some kind of automatic disk defrag tool, or a groovy mouse driver? It's just that after a reboot (or running eclipse 3.0) you usually run ok, then *something* happens and eclipse 3.1 is broken. It seems possible that you, or your system, may have launched something at some point that is messing us up. <g> The reason I ask is that we had a problem where a third party tool (from Telelogic, see bug 87798 comment 31) had a bug in their code that caused the Windows File Dialog to crash. Since we use the native Windows File Dialog, our users were reporting eclipse crashes when they browsed for a file. This is just to show that other (misbehaving) apps can affect us in strange ways. Anyhow, if you could take a snapshot of your Windows Task Manager before and after the problem occurs, there might be some extra process in there that might be a hint to the cause of your troubles... a long shot, but worth a try.
Created attachment 25957 [details] Tasks before and during List of tasks when bug not occuring next to list when bug was there.
(In reply to comment #10) > Well I would hope it wouldn't be a broken mouse as it is my laptops touch pad! I am also having the problem and the only common factor I can see after reading through the comments is that I am also seeing it on a laptop. I sometimes suspect that suspending and/or hibernating makes it more likely that the problem will occur when I resume, but I can't be sure if there is a real correlation here. The versions I am running: Windows XP SP2 + all current critical updates JDK 1.5.0_04 Eclipse Version: 3.1.0 Build id: I20050627-1435
I am not using a laptop but still get the problem.
I see this bug, also on Windows XP SP2. I would characterize it like this (which is mostly redundant with what's been said, but perhaps will help lead someone to the problem): As soon as the focus is moved into an editing window, it grabs the mouse input and disables the keyboard. So I can move the mouse over any other portion of the Eclipse GUI, but the editing window doesn't release it: the mouse cursor doesn't change when I'm over windows borders, I can't press buttons or menu items, etc. And clicking and moving the mouse from well outside the editing window just causes text selection to occur in the editing window. This happens in the Java and CDT perpectives. It happens right after restarting Eclipse. It happens even though I modified eclipse.ini to increase heap and cache to -Xms192m -Xmx512m (from the defaults of 40 and 256). Alt-tabbing away to another app and then back to Eclipse thankfully restores the focus to something outside of the editing windows, but as soon as I click in an editing window, the problem is back. Sometimes the problem includes no response at all to the mouse, but alt-tabbing to another app and back returns the problem to the state described above. I have about 20 projects, but only 5 open with perhaps 300 files total in them. When I start up Eclipse, it normally starts with (status bar) "Automatic Update Search" and that takes a minute or two to complete. Then it does the C/C++ indexer. Waiting until those finish before putting the focus in an editing window doesn't avoid the bug. Before invoking the bug, or immediately after alt-tabbing away and back, mouse and keyboard activity in the non-editing windows (e.g., Package Explorer, Outline) is handled normally. As far as the C++ indexing, I have Cygwin installed (all updated), and eclipse is using the gcc in cygwin. This is a debilitating bug. It started out as an intermittent problem, now even rebooting doesn't fix it. If you need more info, feel free to contact me. Version: 3.1.1 Build id: M20050929-0840 jre 1.5.0_06-b5 CDT 3.0.1 Perforce P4WSAD 2005.2.3562 and other plugins... as I said, more info available on request.
I just noticed one more thing. When the bug is active, the keyboard is not completely disabled. Specifically, Ctrl+Left Arrow moves left by a "word", Ctrl+Right Arrow moves right, Ctrl+Up Arrow scrolls by one line, etc. And Alt+Left arrow moves through editing window tabs (i.e., moves me to editing another buffer). And *sometimes* typing in text works (the text gets inserted or I'm prompted as to whether I want to check out the file for editing). Other times the keyboard is ignored. In all cases, when the bug is active, plain arrow keys, PageUp, PageDown, Home, and End are always ignored (though "Delete" and "Insert" are not).
>As soon as the focus is moved into an editing window, it grabs the mouse >input and disables the keyboard. 1) Does it happen why you tab into the editor? 2) Can you see whether it happens running stand alone SWT (See CAR's comment #26 and comment #27)?
(In reply to comment #37) > >As soon as the focus is moved into an editing window, it grabs the mouse > >input and disables the keyboard. > > 1) Does it happen why you tab into the editor? > 2) Can you see whether it happens running stand alone SWT (See CAR's comment > #26 and comment #27)? > (FYI: lately I've been in a situation where I'm only using Eclipse maybe an hour a day and the problem hasn't recurred using the original setup [post-reboot]. Will continue trying.)
I20060704-0800 I just got the symptoms mentioned in the original comment and comment 35 and the cause of the problem was a stuck mouse button on my mouse. I have a five button mouse where two of the buttons are for browser navigation (forward and backward) and one of these buttons was stuck on. Clicking the button fixed the problem.
Ok, we have a way to debug this now. If anyone on this bug report is still seeing this problem, speak up!!!
(In reply to comment #40) This bug has forced me to use 3.0 since Sept 05. Will switch to 3.2 and let you now if it still occurs.
I can still provoke the problem by waking my laptop from hibernation (or rebooting) when docked with the KVM switch set to a different machine then switching it to the laptop after it has woken up. Windows does not recognise the mouse+keyboard on the first switch to the laptop, but if I switch to some other machine then back to the laptop, the mouse+keyboard work properly for everything except Eclipse (and the ControlExample etc. described in comment #26). I have not had the problem recently under any other conditions so I have been avoiding it by remembering to set the KVM switch before waking up the laptop. This is after a recent upgrade to try out Callisto release process; currently running: Version: 3.2.0 Build id: I20060602-1317 java.vm.version=1.5.0_06-b05
(In reply to comment #41) Problem has come back after switching from 3.0 to 3.2. I have no way to make it happen on demand. I am using XP SP1 and Perforce plugin. Having read comment 42 about the KVM switch I tried bashing my mouse very hard against the desk - this reset/fixed it. I don't seriously think the mouse is at fault. Anyway, if there is something strange about my mouse it doesn't affect eclipse 3.0 or any other application.
I'm adding FH to help on this bug report while I'm gone. Here is the theory: A Windows mouse capture is stuck on in SWT because SWT believes that there is still one mouse button down. SWT won't release the capture on mouse up unless it determines that no button is down (this is what X Windows does). Most Windows applications release the grab when any mouse is released so that's why no other application on the desktop sees it. So in order to test this theory, we need to supply you with a patch that releases the grab and prints out which mouse button is down. The only thing that shoots down this theory is that I have no idea why it works in 3.0 and not in 3.2, unless the code we added to detect button 4 and 5 causes this ... and wait ... it should. If I attach a patch, can you apply it and give us the results?
If you attach a patch appropriate to the version I am running (see comment #42) I will give it a go.
I will also apply the patch but unlike Owen, I have no way to instigate the problem. I am using Eclipse Version: 3.2.0 Build id: M20060629-1905. JVM build 1.5.0_07-b03
Hello Owen and Gordon, do you guys have org.eclipse.swt source loaded in your workspace ? Loaded from CVS I hope. The code that Steve would like you guys to try is to replace the implementation of Widget#wmLButtonUp (int, int, int) by: LRESULT wmLButtonUp (int hwnd, int wParam, int lParam) { LRESULT result = null; if (sendMouseEvent (SWT.MouseUp, 1, hwnd, OS.WM_LBUTTONUP, wParam, lParam)) { result = new LRESULT (callWindowProc (hwnd, OS.WM_LBUTTONUP, wParam, lParam)); } else { result = LRESULT.ZERO; } int mask = OS.MK_LBUTTON | OS.MK_MBUTTON | OS.MK_RBUTTON | OS.MK_XBUTTON1 | OS.MK_XBUTTON2; if (((wParam & 0xFFFF) & mask) == 0) { if (OS.GetCapture () == hwnd) { System.out.println("RELEASED"); OS.ReleaseCapture (); } } else { System.out.println("NOT RELEASED"); System.out.println("\tMK_LBUTTON: " + (((wParam & 0xFFFF) & OS.MK_LBUTTON) != 0)); System.out.println("\tMK_MBUTTON: " + (((wParam & 0xFFFF) & OS.MK_MBUTTON) != 0)); System.out.println("\tMK_RBUTTON: " + (((wParam & 0xFFFF) & OS.MK_RBUTTON) != 0)); System.out.println("\tMK_XBUTTON1: " + (((wParam & 0xFFFF) & OS.MK_XBUTTON1) != 0)); System.out.println("\tMK_XBUTTON2: " + (((wParam & 0xFFFF) & OS.MK_XBUTTON2) != 0)); } return result; } Then run the testcase and paste here the output. We belive that when you let the left button up the xbutton(1|2) is still down.
Please, let me know if you need any help to apply the "patch".
(In reply to comment #48) 1) Could you provide the patch already compiled? 2) What is the test case? I have no way to make the problem happen on demand. For me the gap between occurances could be hours or weeks.
I loaded SWT from CVS (as described at http://www.eclipse.org/swt/cvs.php) and applied the patch described in comment #47. I ran the test using the ControlExample. I started out with everything working normally, when I clicked the mouse in various places the output was: RELEASED I then did the hibernate and KVM thing to provoke the problem and the output on clicking a mouse button was: NOT RELEASED MK_LBUTTON: false MK_MBUTTON: false MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: true I only have two buttons and a wheel on the mouse attached to the KVM! The laptop where this was being done has only left and right buttons (two of each) but it also has a touchpad as well as a pointing stick. The touchpad driver can be configured to have "tap zones" that do various things so I configured one to be button 5 and when I clicked it the output on clicking the normal mouse buttons became: RELEASED I think that this confirms that at least in my case it is a mouse button appearing to be stuck down, but it's a button I don't have on my mouse.
Steve, for some reason the OS reports XBUTTON1 down. Is there anyway to know of the mouse device has XBUTTON1 and XBUTTON2 ?
We could use Raw Input to get this information but there might be another way. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/mouseinput/mouseinputreference/mouseinputmessages/wm_xbuttondown.asp
Also, see GetSystemMetrics() and SM_CMOUSEBUTTONS to get the number of mouse buttons.
Ok, I have released code that only tests for buttons 4 and 5 when they exist. Hopefully, your machine will report that they don't exist and then we won't think they are stuck on. Please get the latest from CVS and give it a try. If it works for you, then I'll mark the problen fixed. Drum roll ...
Unfortunately, the change does not fix the problem for me. OS.GetSystemMetrics(OS.SM_CMOUSEBUTTONS) reports 5 on my laptop and this time it seems to think that both XButtons are down. I suspect that the OS thinks that 5 buttons are available because it is possible to configure the touchpad to generate XButton events. Would it be possible to remember whether or not you have ever seen an XButton event and base the test on that rather than depending on the OS to report their presence correctly? If it is possible to ignore the XButtons until they have been used it should mean that those with XButtons can use them, but those without are not troubled by phantom XButtons.
Yes, that's a good idea. I'll just hack that up ...
Owen, can you hack Widget.wmLButtonUp() and add the following line? System.out.println ("XMOUSE="+ display.isXMouseActive()); I'm still hoping to detect this problem using operating system calls. Thanks.
The solution that remembers when an X button was pressed needs to work if the user plugs in a new mouse. Just setting the flag and never clearing it will have this bug.
I now have the patches from both comment #47 and comment #57 installed so the relevant part of wmLButtonUp is System.out.println("XMOUSE=" + display.isXMouseActive()); if (((wParam & 0xFFFF) & mask) == 0) { if (OS.GetCapture() == hwnd) { System.out.println("RELEASED"); OS.ReleaseCapture(); } } else { System.out.println("NOT RELEASED"); System.out.println("\tMK_LBUTTON: " + (((wParam & 0xFFFF) & OS.MK_LBUTTON) != 0)); System.out.println("\tMK_MBUTTON: " + (((wParam & 0xFFFF) & OS.MK_MBUTTON) != 0)); System.out.println("\tMK_RBUTTON: " + (((wParam & 0xFFFF) & OS.MK_RBUTTON) != 0)); System.out.println("\tMK_XBUTTON1: " + (((wParam & 0xFFFF) & OS.MK_XBUTTON1) != 0)); System.out.println("\tMK_XBUTTON2: " + (((wParam & 0xFFFF) & OS.MK_XBUTTON2) != 0)); } The output when in the buggy mode is: XMOUSE=false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: false MK_RBUTTON: false MK_XBUTTON1: true MK_XBUTTON2: true This looks promising, but since I don't have a mouse with Xbuttons, I cant check that plugging one in would make the test return true.
... but Felipe can. FH, can you check this quickly?
Darn. My mistake. Display.isXMouse() is checking to see whether "focus follows pointer", and X Windows-like mouse mode is enabled. It is not checking for XBUTTONs.
Fixed > 20060731 Owne, please retest with the latest from HEAD and reopen this bug report if not fixed for you. NOTE: The fix only tests for the bits when and XBUTTON has been pressed. It contains the following subtle bug. If, after using button 4 or 5, the user switches from a 3 button mouse to a 5 button mouse without restarting SWT, then SWT will check for buttons 4 and 5, even though they don't exist. Given that this is harmless 99.9% of the time, only the people that were originally affected by this bug will see the problem. The fix, even though not perfect, is better than leaving this bug in. Whew!
... I meant of course, the user switches from a 5 button to a 3 button mouse ... but you get the idea.
My goodness, how about I actually mark this fixed too.
I can confirm that the version built from the latest HEAD fixes the problem for me. (Tested by running ControlExample with new code concurrently with Eclipse still using old code.) Thanks for fixing this.
Yay!
This fix does not work for me - i have the same issues i downloaded eclipse-SDK-I20060801-0900-win32.zip and i get the same problem as described here again. I tried several things, including setting up the heap size for eclipse... The only difference is that i have indeed a 5(6) button mouse - the Inteli Mouse 3 from Microsoft.. this is really bugging me, i have this problem since eclipse 3.0 =(
Please run the code from comment #47 to see whether there there is a button stuck down.
(In reply to comment #68) I now have a way to make the problem happen on demand. I have two USB mice connected to same computer. One has 5 buttons and the other has three. A switch will reconnect the 5 button mouse to a different computer. Pressing the switch twice causes the problem. Banging the 5 button mouse clears it. Can you provide the code from comment #47 already compiled?
See http://www.eclipse.org/swt/cvs.php for instructions to run SWT from HEAD (the same way the committers do).
(In reply to comment #68) > Please run the code from comment #47 to see whether there there is a button > stuck down. > I checked out the head - modified the Widget Class and played around in the control example - here is the output : I was clicking around on the first tab , then using the right mouse button - then the middle one for scrolling and then it happend - the middle button (wheel+button in one) seems to be "stuck" for eclipse - but it really is not - after clicking multiple times on the middle button it got unstuck again RELEASED RELEASED RELEASED RELEASED RELEASED RELEASED RELEASED RELEASED RELEASED RELEASED NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false NOT RELEASED MK_LBUTTON: false MK_MBUTTON: true MK_RBUTTON: false MK_XBUTTON1: false MK_XBUTTON2: false RELEASED RELEASED RELEASED RELEASED RELEASED RELEASED
That's interesting. It really sounds like a hardware problem to me. Not sure what to do about it except see whether other applications on the desktop think the middle button is down. Mouse grabbing in SWT (called mouse capture in win32) based on the X Windows behavior. On X, if a button is down, there is a grab. So, to be consistent and portable between Windows and X Windows based systems, SWT ensures that win32 mouse capture is not released until every button is released, the same way it happens on X. Normally, native Windows applications only capture the mouse for the left button. So, I can't change this behavior without breaking portability. I can give you a patch or you can hack SWT to fix it for your machine, but I couldn't ever release the code.
thats ok i guess - what would the actual fix be ? just comment out any mouse events for the middle button ?
Yes, comment it out of any mask.
*** Bug 108422 has been marked as a duplicate of this bug. ***
*** Bug 155296 has been marked as a duplicate of this bug. ***
*** Bug 115640 has been marked as a duplicate of this bug. ***
