Community
Participate
Working Groups
When scrolling vertically in the drop down, either with the keyboard keys or a click on the scroll bar, if the CCombo is in a form nested in a Shell that also has a vertical scroll bar, the shell scrolls in the sameway the CCombo drop down does.
Created attachment 30607 [details] Error example in eclipse product editor The drop down containing the value for the CCombo "Specify the application to run when launching this product" is way below the CCombo text field, because the parent shell scroll bar "followed" the one from te CCombo drop down.
Created attachment 30608 [details] Another example on an application of mine Again, the drop down showing the possible values of the CCombo labelled "F.E. visuelle", is way below its defining CCombo as the containing ScrollableForm "followed" scrolling the drop-down scrolling.
In fact, it is not linked to the fact that the parent shell has a vertical scroll bar, but that the CCombo is within a Scrollable container.
This is probably not a CCombo bug. Duong to prove this by writing a simple test case that shows a popup list also scrolls badly. Then give the bug to me or Felipe.
Is it possible that listeners are being added to do the scrolling by virtue of calling formToolkit.adapt(ccombo, true, true) on the control?
Duong?
This behavior is not reproducible in 3.5M6. Verified it in eclipse product editor. Also verified it by creating a sample view which uses a scrolled form.
Created attachment 132508 [details] simple plugin for scrolled form view
I was testing a different bug using Scrolled Composite and CCombo and was able to reproduce this bug, but with different steps. It is reproducible with 3.5RC3, using a simple SWT snippet with CCombo inside a ScrolledComposite. Steps: 1) Click on the CCombo's arrow button so that the drop-down pops up. 2) While the dropdown is still popped-up, try to scroll the Composite (don't scroll the dropdown or the CCombo) ------------------------------------- SWT Snippet to reproduce the problem: ------------------------------------- import org.eclipse.swt.SWT; import org.eclipse.swt.custom.CCombo; import org.eclipse.swt.custom.ScrolledComposite; import org.eclipse.swt.layout.GridData; import org.eclipse.swt.layout.GridLayout; import org.eclipse.swt.widgets.Button; import org.eclipse.swt.widgets.Combo; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class ComboScroll { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); final ScrolledComposite sc = new ScrolledComposite(shell, SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL); sc.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true, 1, 1)); Composite c = new Composite(sc, SWT.NONE); c.setLayout(new GridLayout(1, true)); CCombo ccombo = new CCombo(c, SWT.BORDER); for (int i = 0; i < 5; i++) ccombo.add("ccombo " + i); Combo combo = new Combo(c, SWT.BORDER); for (int i = 0; i < 5; i++) combo.add("combo " + i); for (int i = 0; i < 10; i++) { Button b = new Button(c, SWT.PUSH); b.setText("Button " + i); } sc.setContent(c); sc.setExpandHorizontal(true); sc.setExpandVertical(true); sc.setMinSize(c.computeSize(SWT.DEFAULT, SWT.DEFAULT)); sc.setShowFocusedControl(true); shell.setSize(300, 300); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Lakshmi, please see if you can find a fix for this.
Created attachment 141527 [details] patch This behavior is seen with CCombo on all platforms. The patch modifies the behavior such that, when the CCombo's drop-down is visible and the user tries to scroll the containing composite, the drop-down is closed and the composite is scrolled. The bug is seen on Windows and Carbon native Combo too. The patch doesn't fix the native Combo behavior.
Created attachment 141528 [details] test case - CCombo inside a Scrollable composite
*** Bug 275885 has been marked as a duplicate of this bug. ***
Created attachment 155799 [details] movie I don't any improvement with the patch. It's possible that I'm misunderstanding the bug though. There are some problems with scrolling with the mouse wheel while the CCombo is open. I've attached a screen cast of bad scrolling behaviors. You'll notice that if the mouse is over the parent composite, it's scrolled, but the CCombo's popup does not. Also if the mouse is over the CCompo's popup, the mouse wheel gets delivered to the app behind the active app (see package explorer scrolling in the background). I get the same behavior with and without the patch. (sorry about the poor quality of the screen cast.)
the package explorer scrolling thing is only happening with Combo, not CCombo so that's not related to this bug. Seems that something is wrong with MouseWheel events though.
Hi Kevin, I tried to reproduce this bug on windows and currently not able to see it. I was able to reproduce it on windows before. :( The problem seen in the movie is the bug. When we scroll the composite with the CCombo drop-down is visible, the drop-list is still visible and detached from the CCombo. I can easily reproduce this on Linux-Gtk & Mac and applying the patch fixes the scrolling issue. I'll try to find another windows machine to reproduce this bug.
I tried this bug on another Windows machine but I'm not able to reproduce this on windows anymore. Does anybody see this on windows with the 3.6 latest? As before, it is reproducible on the other platforms - cocoa, carbon, gtk.
This is an usability bug still happening on Mac & GTK. Carolyn, can it go for RC1?
Created attachment 167756 [details] final patch Lakshmi, the patch just needs the following change: if (event.widget instanceof ScrollBar && event.type == SWT.Selection) { handleScroll(event); return; } should become: if (event.type == SWT.Selection) { if (event.widget instanceof ScrollBar) { handleScroll(event); } return; } Though the first block above doesn't cause a problem under normal circumstances, it did lead to a ClassCastException in the subsequent "Shell shell = ((Control)event.widget).getShell ();" line when stepping through a debugger if I selected something like a ToolItem. Here is a patch that's identical to yours but with this change added. Please commit this patch to HEAD, I'll +1 the report in the next comment.
Thanks Grant. Fixed in HEAD > 20100511
