Community
Participate
Working Groups
Build Identifier: M20110210-1200 I have extended the Canvas class to create an expandable section control when The code is called the first time the composite is created when the code is called to draw focus the method org.eclipse.swt.graphics.GC.drawFocus (int x, int y, int width, int height) which on the second line has this check: if ((data.uiState & OS.UISF_HIDEFOCUS) != 0) return; In the debugger I could see that data.uiState is always 3, so drawFocus() always exits without doing anything. on other versions of windows there is no issue and if the widget is recreated a second time there is no issue. It's not clear how the uiState is getting set differently on different OS's or why the second time creating the widget on a new composite makes the uiState 0 Reproducible: Always
The behavior is correct, if you press ALT once while you window is up the ui state will change the focus rect will start drawing. Alternatively we can change windows preferences to always show the focus ring.
So is there a way that through code I can have widgets I create that extend the canvas class display the focus We have radio buttons, combo boxes and others that get the focus but don't show the focus the first time the form they are displayed on is created on windows 7 but the second time the focus is displayed. On other versions of windows and linux we don't have this issue. Is there something we are supposed initialize in the control or the composite so the focus will display.
SO I reopened this bug because the widgets I created that extended the canvas class do not display focus the very first time I display them only on windows 7. I don't understand how to get the UI state set for them but also combo boxes and radio buttons. Is there something I am supposed to call to init this UIstate for windows 7 that I don't need on other system. This setting for windows 7 that you mentioned I could not find. Any help would be appreciated.
The issue seems to be if the controls are opened within the edtior view within a CTabFolder the CTabfolder UI state needs to be cleared of the Hide Focus on the first time the tab is created.
Hi Garry, not sure why this work around did not work: void updateforFocus(Composite control) { Event e= new Event(); e.type= SWT.KeyDown; e.keyCode= SWT.ALT; control.getDisplay().post(e); e.type= SWT.KeyUp; control.getDisplay().post(e); } What you could try instead, is to change your workaround: void updateforFocus(Composite control) { int /*long*/ hwndShell = control.getShell ().handle; int uiState = /*64*/(int)OS.SendMessage (hwndShell, OS.WM_QUERYUISTATE, 0, 0); if ((uiState & OS.UISF_HIDEFOCUS) != 0) { OS.SendMessage (hwndShell, OS.WM_CHANGEUISTATE, OS.MAKEWPARAM (OS.UIS_CLEAR, OS.UISF_HIDEFOCUS), 0); } } to use reflection and only run it when SWT.getPlatform() == "win32".
Garry, try this code: public static void main(final String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new RowLayout()); Label label = new Label(shell, SWT.SINGLE); label.setText("text:"); final Combo combo = new Combo(shell, SWT.DROP_DOWN | SWT.READ_ONLY); combo.setItems(new String[] {"hello", "hi"}); combo.select(0); Button button = new Button(shell, SWT.PUSH); button.setText("button"); display.addFilter(SWT.KeyDown, new Listener() { public void handleEvent(Event event) { if (event.keyCode == SWT.F1) { combo.redraw(); System.out.println("redrawing"); } } }); shell.setSize(200, 200); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } note that when the window open the focus ring is not visible. When I press Alt the focus ring shows around the combo. Adding: Event e= new Event(); e.type= SWT.KeyDown; e.keyCode= SWT.ALT; display.post(e); e.type= SWT.KeyUp; display.post(e); After shell.open() causes the windows to show with the focus ring showing.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.