Community
Participate
Working Groups
I have a dialog with some fields. Pressing ok saves the content of those fields. It works well on windows. On Mac OS X Lion not. Steps to reproduce: 1. Create a form with fields (or download http://wiki.eclipse.org/Scout/Tutorial/Project_From_Existing_Workspace) 2. Open the form as dialog 3. Change a value in a field and click "cancel". The messagebox "Save changes?" should appear. It does not. 4. Open the dialog again, change a value in a field and press tab before clicking cancel. The messagebox appears -> fine Btw: If I press the enter key it saves the value. If I use the mouse and click ok without leaving the field first, it does not.
Input from juewe at: http://www.eclipse.org/forums/index.php/mv/msg/384383/924486/#msg_924486
You can also produce such a situation under windows, if you use a ToolButton bar in your form [1]. In this case, there is also no lost_focus event on the SWT Field corresponding to the Scout Value Field. The Scout model has no information about the current value in the UI, leading to unexpected behavior for the user. [1] http://www.eclipse.org/forums/index.php/t/631535/
A similar problem is solved in RWT, where there is no focus lost when ESC is used: See RwtUtility.verifyUiInput(focusControl); in org.eclipse.scout.rt.ui.rap.window.dialog.RwtScoutDialog.DialogImpl.close() The UI value of the field containing the focus is written to the model when the dialog is closed. Something similar could be done when a toolbutton or ok button is clicked.
We discussed an additional case (similar to what Judith has described): If you call doOk() in the execAction() of a KeyStroke, there is also no lost focus event.
Pushed change to gerrit: https://git.eclipse.org/r/#/c/20929/
Commit for 3.10.0-M5: 6a151d0739c5c98ec249e1f667ba557ca40b7ccf http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?id=6a151d0739c5c98ec249e1f667ba557ca40b7ccf @Claudio Guglielmo: Can you verify please?
Additional commit for this bug (3.10.0-M5): f227a697cb4bc2f5a4b823976d250498ad5abae2 http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?id=f227a697cb4bc2f5a4b823976d250498ad5abae2 This is in order to support following use case: - value V1 in the SmartField - [Down][Down][Down] (to select an other Value: V2) + [Tab] - value V2 should be set in the SmartField.
Hi all I think that a commit for this bug breaks the functionality of tray icon menus for an SWT client. More specifically, when a tray icon menu is clicked, AbstractSwtMenuAction.handleSwtAction() is triggered. Here, a new check with SwtUtility.runSwtInputVerifier fails (returns false), because there is no currently focused control. As a consequence, the menu action is not executed.
see comment 8
Hi Lukas, thank you very much for your analysis, you are right. Pushed a new patch to gerrit: https://git.eclipse.org/r/#/c/21792/
to be fixed on branch 3.10 as well
committed on develop http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?id=56f23beccee625bbc49584a79a7f51fe6a813e7f
pushed backport to 3.10 to gerrit: https://git.eclipse.org/r/#/c/22980/
changed was merged to 3.10 with commit http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?h=release/3.10.0&id=9ec39f7063291c3b61cd4babbb15146b960a8c22 @Erich, can you please verify?
tested with 3.10.0.20140314-1207 -> Test OK
see comment 15
The use case described in comment #2 is not working. See Bug 435052.
Shipped with Eclipse Luna Release
