Bugzilla – Full Text Bug Listing
| Summary: | SWT: Scout model value not updated because of a missing lost focus event | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Claudio Guglielmo <claudio.guglielmo> |
| Component: | Scout | Assignee: | Project Inbox <scout.core-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | dev, erich.steiger, jeremie.bresson, judith.gull, lhu, zimmermann |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Claudio Guglielmo
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. 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 |