Community
Participate
Working Groups
N20060421-0010. 1. install fresh Eclipse SDK 2. start 3. Window > Preferences > Java > Editor > Templates 4. select a row in the table 5. press 'Cancel' 6. Window > Preferences > Java > Editor > Templates 7. use the mouse wheel to scroll the table ==> screen cheese
Created attachment 39154 [details] Picture with cheese (sorry no Swiss one)
This is working for me (in the ControlExample). This is a Windows bug that is supposed to have been already worked around (but might be missing for the mouse wheel case). I noticed in the screen shot that you aren't running with the Window XP theme (or your theme looks a lot like Windows 2000).
Also, I love Swiss cheese the best!
>I noticed in the screen shot that you aren't running with the >Window XP theme (or your theme looks a lot like Windows 2000). Correct, I'm a very old-fashioned guy.
Can't make it happen. Can you make it happen with this code (if not, can you edit this code to make it happen?): import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; public class PR_137916 { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); Table table = new Table(shell, SWT.MULTI); table.setSize(400, 200); table.setLinesVisible(true); table.setHeaderVisible(true); String[] columnTitles = { " ", "C", "!", "Description", "Resource", "In Folder", "Location" }; for (int i = 0; i < columnTitles.length; i++) { TableColumn tableColumn = new TableColumn(table, SWT.NULL); tableColumn.setText(columnTitles[i]); } for (int i = 0; i < 128; i++) { TableItem item = new TableItem(table, SWT.NULL); item.setText(0, "x"); item.setText(1, "y"); item.setText(2, "!"); item.setText(3, "None of this stuff behaves the way I want"); item.setText(4, "Almost_Everywhere"); item.setText(5, "Some.darn.folder man"); item.setText(6, "line " + i + " in Nowhere"); } for (int i = 0; i < columnTitles.length; i++) { table.getColumn(i).pack(); } shell.pack (); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
>Can't make it happen. By following steps from comment 0? Also note that I do not use the manifest.
WORKSFORME following the steps. When you say in step 4, "select a row in the table", do don't mean double click do you? Also, in step 6, the window comes back with the focus in another widget. I need to first click in the table before the mouse wheel works. Can you make the simple example fail?
In the latest SWT, the manifest is not needed.
>4. select a row in the table by single-click >Also, in step 6, the window comes >back with the focus in another widget. I need to first click in the table >before the mouse wheel works. No, I simply use the scroll wheel and the table scrolls Just tried again using I20060428-0010.
Where is focus? Does the simple code fail?
Sorry, I didn't have time yet to try this and guessed that the provided steps would be simple enough to reproduce. The focus is in the filter text entry field.
It's not a big deal and can wait. The focus for me is in the text field so the mouse wheel won't scroll the table until I click in it.
I agree, it's not a big deal. Maybe an old vs. XP style issue? I didn't use TweakUI to tweak my mouse. Really strange: when I manually set the focus on the Preview or the tree the mouse wheel does not work but when I manually set the focus to the filter entry field then the wheel works on the table. I'll see whether I find time tomorrow to try you snippet.
...and step 3-5 are crucial
The snippet works for me.
Simpler steps showing cheese in Eclipse about info: 1. start fresh workspace 2. select Help > About Eclipse SDK 3. click 'Plug-in Details' 4. select an entry 5. click 'More Info' 6. go back to dialog 7. use mouse wheel ==> cheese
I also get this problem. I'm developing an RCP application that uses a lot of tables, and I'm seeing the problem using XP theme as well as Classic theme. It also happens for me when running the test case in comment #5. I think this is a big deal. I'm writing an RCP/Birt app to replace an Access database (which has to be a Good Thing, right?), and if the first thing the users sees is their tables turning to mush just by using the scroll wheel, they are not going to be happy and are going to shout to have their Access db back. Please fix this soon - I'd be happy to help with more test cases etc.
Created attachment 51457 [details] Screenshot of cheese happening with simple test case
Colin, can you make the problem happen with SWT from HEAD?
I can reproduce with steps from comment 10
I believe this is fixed in 3.2.1 - I can no longer reproduce the cheese when running my app under 3.2.1. I would be happy to close as fixed.
No it is not fixed. Simply use the steps from comment 16 (except that the 'More Info' button has gone - click 'Legal Info' instead).
Glad it's fixed for you Colin. I'll have another go at finding out what is going on for Daniel. Like I said, it's a Windows bug that I though I had worked around.
I use the Windows classic look - just in case that matters.
Daniel, what version are you using? I am using a fresh install of Eclipse 3.2.1 build M20060921-0945, SWT version 3.2.1.v3235e, running on Windows XP SP2 with Windows Classic theme. I tried the steps in comment 16, and I can't reproduce the problem.
Created attachment 60050 [details] Cheese I use I20070228-0930 but also see the bug in 3.2.1 and 3.2.2.
This bug is still alive in Europa: Version: 3.3.0 Build id: I20070625-1500 I'm using Windows XP with the default XP theme.
> Windows XP with the default XP theme. Can you attach a screen shot? There is a theory that it only happens using the classic theme.
Dani, do you need to follow the steps exactly? Do you need a fresh Eclipse? Must you select a row and cancel? FH, you seem to be good at getting cheese on your machine when I can't. Can you have a quick go at making this happen?
>Dani, do you need to follow the steps exactly? Do you need a fresh Eclipse? >Must you select a row and cancel? Got it: the really important part is to move the focus away from the table: Simpler steps showing cheese in Eclipse about info: 1. start *any* workspace 2. select Help > About Eclipse SDK 3. click 'Plug-in Details' 4. move focus to another widget (e.g. 'OK' button by pressing the Tab key) 5. use mouse wheel ==> cheese Now, with this knowlodge I can also slightly modify your simple snippet from comment 5 by adding these lines after "Shell shell = new Shell(display);": shell.setLayout(new FillLayout()); new Button(shell, SWT.NONE); 1. start snippet (oh - ugly layout - sorry ;-) 2. press Tab to set the focus to the button 3. use mouse wheel ==> cheese NOTE: I switched to use Windows XP style but same bug (see attached picture). Didn't restart my machine though, just changed it via Display settings.
Created attachment 75299 [details] Cheese (non-classic style)
I concur - following the steps in comment #30 I get the cheese using Eclipse 3.3.0. I am still also seeing this in 3.2.1 as well (or at any rate IBM Rational Application Developer v7, which is based on Eclipse 3.2.1 - it uses SWT 3.2.1.v3235e). Running my app (as mentioned in comment #17) with Eclipse 3.3.0, I now see the cheese again, which wasn't happening in 3.2.1, so I wonder if there has been a regression?
On my machine, the table will not scroll when focus is in the button. I will work with Felipe to try and recreate it.
(In reply to comment #33) > On my machine, the table will not scroll when focus is in the button. I will > work with Felipe to try and recreate it. Daniel, the windows default behaviour is to scroll the focus widget with the mouse wheel. Do you have a special mouse software (usually comes with the mouse driver) that allows you to configure windows to always send the events to the widget under the cursor ?
Logitech SetPoint Control Center 2.11.459. There's no special setting, but yes - it always scrolls the "nearest" scrollable which I think is goodness. I wouldn't expect the button to do some fancy dance for me when I use the scroll wheel while it has focus ;-)
(In reply to comment #35) > Logitech SetPoint Control Center 2.11.459. I have Logitech SetPoint installed on my Vista machine, I can follow the steps but I can't reproduce the problem. On XP, I can't follow the steps cause the table won't scroll if it doesn't have the focus.
Bummer! Can I do something on my machine to help you debug the issue?
Yes, you can help. The work around code for the drawing bug is in Table.WM_VSCROLL(). On my machine, WM_VSCROLL is not called when the user scrolls with the wheel (I swear it used to be called). Table.WM_VSCROLL() contains work around code that sees how the table was scrolled and damages the exposed items. /* * Bug in Windows. When a table is drawing grid lines and the * user scrolls vertically up or down by a line or a page, the * table does not redraw the grid lines for newly exposed items. * The fix is to invalidate the items. */ In any case, it seems an implementation of Table.WM_MOUSEWHEEL() is needed on some machines that has a similar sort of work around. 1) Can you tell me whether WM_VSCROLL is called from WM_MOUSEWHEEL on your machine? 2) Can you confirm that the bug happens only happens when the button has focus (or does it happen when the table has focus too)?
>1) Can you tell me whether WM_VSCROLL is called from WM_MOUSEWHEEL on your >machine? It is NOT called when the table has focus but when the focus is on the button it gets called: Thread [main] (Suspended (breakpoint at line 5566 in Table)) Table.WM_VSCROLL(int, int) line: 5566 Table(Control).windowProc(int, int, int, int) line: 3752 Table.windowProc(int, int, int, int) line: 5027 Display.windowProc(int, int, int, int) line: 4377 OS.DispatchMessageW(MSG) line: not available [native method] OS.DispatchMessage(MSG) line: 2283 Display.readAndDispatch() line: 3317 AboutPluginsDialog(Window).runEventLoop(Shell) line: 825 AboutPluginsDialog(Window).open() line: 801 AboutDialog.buttonPressed(int) line: 117 Dialog$2.widgetSelected(SelectionEvent) line: 621 TypedListener.handleEvent(Event) line: 227 EventTable.sendEvent(Event) line: 66 Button(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3708 Display.readAndDispatch() line: 3319 AboutDialog(Window).runEventLoop(Shell) line: 825 AboutDialog(Window).open() line: 801 AboutHandler.execute(ExecutionEvent) line: 35 HandlerProxy.execute(ExecutionEvent) line: 239 Command.executeWithChecks(ExecutionEvent) line: 475 ParameterizedCommand.executeWithChecks(Object, Object) line: 429 HandlerService.executeCommand(ParameterizedCommand, Event) line: 165 SlaveHandlerService.executeCommand(ParameterizedCommand, Event) line: 247 ActionFactory$WorkbenchCommandAction(CommandAction).runWithEvent(Event) line: 178 ActionContributionItem.handleWidgetSelection(Event, boolean) line: 545 ActionContributionItem.access$2(ActionContributionItem, Event, boolean) line: 490 ActionContributionItem$5.handleEvent(Event) line: 402 EventTable.sendEvent(Event) line: 66 MenuItem(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3708 Display.readAndDispatch() line: 3319 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2389 Workbench.runUI() line: 2353 Workbench.access$4(Workbench) line: 2219 Workbench$4.run() line: 466 Realm.runWithDefault(Realm, Runnable) line: 289 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 461 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 106 EclipseAppHandle.run(Object) line: 169 EclipseAppLauncher.runApplication(Object) line: 106 EclipseAppLauncher.start(Object) line: 76 EclipseStarter.run(Object) line: 363 EclipseStarter.run(String[], Runnable) line: 176 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 585 Main.invokeFramework(String[], URL[]) line: 508 Main.basicRun(String[]) line: 447 Main.run(String[]) line: 1173 Main.main(String[]) line: 1148 >2) Can you confirm that the bug happens only happens when the button has focus >(or does it happen when the table has focus too)? Definitely: when the table has focus there's no cheese.
Ok, we are getting close. Please step through the work around code and see whether it is damaging the right area. You will see the work around in the switch statement that ends up calling OS.InvatidateRect().
These are the table bounds: Rectangle {9, 11, 609, 345} and the attached pic will show the debug info. Below is the stack trace. Note sure whether this matters: when I scroll and then step through in the debugger I hit WM_VSCROLL several times but OS.invalidateRect is not always called. Thread [main] (Suspended (breakpoint at line 5609 in Table)) Table.WM_VSCROLL(int, int) line: 5609 Table(Control).windowProc(int, int, int, int) line: 3752 Table.windowProc(int, int, int, int) line: 5027 Display.windowProc(int, int, int, int) line: 4390 OS.DispatchMessageW(MSG) line: not available [native method] OS.DispatchMessage(MSG) line: 2283 Display.readAndDispatch() line: 3317 AboutPluginsDialog(Window).runEventLoop(Shell) line: 825 AboutPluginsDialog(Window).open() line: 801 AboutDialog.buttonPressed(int) line: 117 Dialog$2.widgetSelected(SelectionEvent) line: 621 TypedListener.handleEvent(Event) line: 227 EventTable.sendEvent(Event) line: 66 Button(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3708 Display.readAndDispatch() line: 3319 AboutDialog(Window).runEventLoop(Shell) line: 825 AboutDialog(Window).open() line: 801 AboutHandler.execute(ExecutionEvent) line: 35 HandlerProxy.execute(ExecutionEvent) line: 239 Command.executeWithChecks(ExecutionEvent) line: 475 ParameterizedCommand.executeWithChecks(Object, Object) line: 429 HandlerService.executeCommand(ParameterizedCommand, Event) line: 165 SlaveHandlerService.executeCommand(ParameterizedCommand, Event) line: 247 ActionFactory$WorkbenchCommandAction(CommandAction).runWithEvent(Event) line: 178 ActionContributionItem.handleWidgetSelection(Event, boolean) line: 545 ActionContributionItem.access$2(ActionContributionItem, Event, boolean) line: 490 ActionContributionItem$5.handleEvent(Event) line: 402 EventTable.sendEvent(Event) line: 66 MenuItem(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3708 Display.readAndDispatch() line: 3319 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2389 Workbench.runUI() line: 2353 Workbench.access$4(Workbench) line: 2219 Workbench$4.run() line: 466 Realm.runWithDefault(Realm, Runnable) line: 289 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 461 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 106 EclipseAppHandle.run(Object) line: 169 EclipseAppLauncher.runApplication(Object) line: 106 EclipseAppLauncher.start(Object) line: 76 EclipseStarter.run(Object) line: 363 EclipseStarter.run(String[], Runnable) line: 176 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 585 Main.invokeFramework(String[], URL[]) line: 508 Main.basicRun(String[]) line: 447 Main.run(String[]) line: 1173 Main.main(String[]) line: 1148
Created attachment 75788 [details] Debug variables
1) Try doing "OS.InvalidateRect(handle, null, true)" always in Table.WM_VSCROLL(). Does the cheese go away (but it might flash)? 2) The SB_LINEDOWN and SB_LINEUP case is attempting to damage a single line. Try multiplying itemHeight by 3 (or more). Does the cheese go away?
>1) Try doing "OS.InvalidateRect(handle, null, true)" always in >Table.WM_VSCROLL(). Causes flickering but fixes the cheese once I stop scrolling. >2) The SB_LINEDOWN and SB_LINEUP case is attempting to damage a single line. >Try multiplying itemHeight by 3 (or more). Does the cheese go away? Still cheese with x50 but no cheese if x100. But also here flickering.
Is there an update on this bug?
*** Bug 249861 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
