Community
Participate
Working Groups
1. Run the snippet below. 2. Hit the <- key. 3. The sash moves right. 4. Likewise, the -> key moves the sash to the left. I'm not sure if bidi rules makes sense here. Shouldn't it do what the user is seeing _visually_ given that I am not trying to enter text here? Display display = new Display(); Shell shell = new Shell(display, SWT.SHELL_TRIM | SWT.RIGHT_TO_LEFT); shell.setSize(400, 300); final Sash sash = new Sash(shell, SWT.BORDER | SWT.VERTICAL | SWT.RIGHT_TO_LEFT); sash.setBounds(180, 10, 32, 240); sash.addListener(SWT.Selection, new Listener() { public void handleEvent(Event e) { sash.setBounds(e.x, e.y, e.width, e.height); } }); shell.open(); sash.setFocus(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose();
For me it is worse than you described. If I move the sash at least one time using the mouse, then left arrow key and right arrow key will both move the sash to the right.
(In reply to comment #1) > For me it is worse than you described. If I move the sash at least one time > using the mouse, then left arrow key and right arrow key will both move the > sash to the right. Confirmed on my computer. It becomes quite odd because one key will move the sash a tiny bit while the other key will move it a lot further. Sometimes I cannot get this double-right behaviour to stick but the difference in step size does show up if the mouse is used. For referencing purposes, I found this while looking at bug 203849.
I noticed there are mistakes when moving to the right when neither the Shell nor the Sash are RTL , using the code below import org.eclipse.swt.SWT; import org.eclipse.swt.widgets.Listener; import org.eclipse.swt.widgets.Sash; import org.eclipse.swt.widgets.Shell; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Event; public class Main_all_ltr { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display, SWT.SHELL_TRIM ); shell.setSize(400, 300); final Sash sash = new Sash(shell, SWT.BORDER | SWT.VERTICAL); sash.setBounds(180, 10, 32, 240); sash.addListener(SWT.Selection, new Listener() { public void handleEvent(Event e) { sash.setBounds(e.x, e.y, e.width, e.height); } }); shell.open(); sash.setFocus(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Created attachment 198354 [details] an incomplete, buggy fix I can see that the problem of moving the other way around happens even when neither the control nor the shell are RTL oriented, there are a couple of native calls which I am not 100% understanding what they are doing, but I made an incomplete, buggy fix which at least makes the Sash moves according to the keyboard arrow direction, the behavior used to be inconsistent and most of the time wrong (even when nothing is "Right to Left") I am posting this fix as a proposal as it ignores a lot of code which must be doing necessary things (to prevent the Sash from moving outside the range of the Shell as a start) , so that more experienced reviewers can have a look and give me directions if possible, thanks a lot for your time and help on advance
The fix works but it is not doing the right thing in my opinion. The entire /* Calculate the new x or y position */ section in WM_KEYDOWN should be rethink. - It should call MapWindowPoints with are RECT (instead of a POINT)
The fix works but it is not doing the right thing in my opinion. The entire /* Calculate the new x or y position */ section in WM_KEYDOWN should be rethink. - It should call MapWindowPoints with are RECT (instead of a POINT), this should handle the case where the orientation of the parent and the sash are not the same - It should not use lastX,lastY,startX,startY as this variables might not be initialized. The code should get these values every time.
fixed http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=86e590387fc98740eb431ea80c5942750b2c6d0c
