Bugzilla – Full Text Bug Listing
| Summary: | [CellEditors] Expose CellEditorActionHandler#updateActionsEnableState() | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pratik Shah <ppshah> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | susan, Tod_Creasey |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 75096 | ||
|
Description
Pratik Shah
too late for 3.1? I'm afraid so. Pratik - can you please expand upon your first comment? In what cases should the actions be updated that we are not currently handling? It sounds like there are particular listeners that need to be added for different kinds of cell editors. Attaching your workaround code would help in explaining the problem. If it seems like a general problem and that extending the action handler is the right solution, we can make the method protected, but I want to explore whether this can/should be fixed inside. Currently, if you bring up a TextCellEditor with two words (say "some text") and all the text selected, you can follow these steps to see that the actions are not enabled properly: Hit "End" key. At this point copy, cut and delete should be disabled, but are not. Hit Ctrl+Shift+Left Arrow to select the last word. At this point copy, cut and delete should be enabled, but they are not. Again hit Ctrl+Shift+Left Arrow to select everything and then hit the backspace key to delete everything. At this point, cut, copy and delete are still enabled. This is reproducible in GEF's logic example. We do not have a workaround for this right now. The problem here is that the action's state at all times is what it should've been before the last keystroke, and is really caused by TextCellEditor. This bug was introduced by the fix for bug 14201. TextCellEditor updates the actions' enablement on keyPressed() instead of keyReleased(), and hence before the change resulting from that keystroke is applied. As a result, the actions' enablement state is always one keystroke behind. There is a comment in TextCellEditor#createControl() that says that mouse and key listeners are used to determine selection changes because selection listeners are not supported. However, I see an addSelectionListener() in Text now (that probably wasn't there originally). Maybe the TextCellEditor can switch to using that mechanism? That will simplify the code, fix this problem, and hopefully won't break the API (since TextCellEditor is marked as not to be subclassed). Otherwise the simpler solution would be to update the actions' state not just when the key is pressed, but also when it is released. Sounds like a great opportunity to use asyncExec ;-) *** Bug 83474 has been marked as a duplicate of this bug. *** *** Bug 97732 has been marked as a duplicate of this bug. *** just tried this using the propertysheet example and the menu seems to be correct all the time... Eric, can you clarify how you verified this? I am still seeing this problem in the property sheet with the EMF Ecore editor in 3.3RC4. > just tried this using the propertysheet example and the menu seems to be
> correct all the time...
I imagine Pratik is referring to the actions that are associated with keybindings. There is also a native context menu for a text control, but its contents are not related to the problem.
Randy, I tried the scenario as described in comment #4...these are all 'standard' commands used by the Text control itself. It's conceivable that there may be some 'bound' Copy/Paste command in the ECore code itself I suppose... Pratik, What I did was to start a fresh workspace, connect to CVS and check out 'org.eclipse.ui.examples.propertysheet'. This is our reference implementation. Then run an 'inner' (i.e. through the 'Run/Debug' menu). In the inner, create a project (any type), add a file "foo.usr" to it. It should open the file and the Outline view should be showing some names (of golfers). If you open the Properties view at this point and select a name in the Outline you should see that person's 'properties'. At this point I activated a text editing control and ran your scenarios... As Randy mentioned in comment 10, I am talking about the copy/cut/paste actions under the Edit menu of the menubar, not on the cell editor's context menu. Is that what you were checking, Eric? Aha, yes indeed that was what I was looking at...I'll re-test and get back. 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. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie. |