Community
Participate
Working Groups
Build Identifier: I20100921-1024 Problem exhibited in Eclipse 3.6 and 3.6.1, only under Cocoa builds (32 and 64 bit). I tried overriding the TextCellEditor to change doSetFocus to not call setFocus and in this case, the text control appears as normal and does not defocus/dismiss. Of course there is no cursor in the text control. However, I do note that if "tab" is hit at this point, focus will go to the text control and it does not defocus/dismiss. I also tried a variety of other tactics including modifying the enablement of the control, using other select mechanisms instead of setFocus/selectAll. I also tried doing the setFocus in an async display runnable, and other actions in the runnable. I also tried changing the text content to temporarily not be empty in doSetFocus. (and change it back immediately after setFocus, or later in async runnable) Only one thing worked to behave "somewhat correctly": in doSetFocus, avoid calling setFocus. instead, create a timed display runnable to call setFocus later. if (later <= 550 milliseconds) this doesn't work. if (later >= 700 milliseconds) it seems to work reliably. if (later == 600 milliseconds) it works sometimes. Is this perhaps related to Bug 313208 Reproducible: Always Steps to Reproduce: 1. On a Tree, use a TextCellEditor for editing the cell 2. Click on the cell to activate the editor for a cell which has an empty string as value 3. The text control appears and has normal behavior 4. Deselect the editor by clicking in the empty part of the Tree 5. Click on the same cell again 6. The text control appears and the cursor flashes 7. After about 50 milliseconds the text loses focus and disappears
Since the time involved was close to Display.getToolTipTime() I also tried using reflection to make the Display.hoverTimer a no-op. This didn't help.
Another thing I tried was to issue SWT.TRAVERSE_TAB_NEXT programatically, first instead of the setFocus, and then also in a later async display runnable. This had the same behavior as setFocus. (I saw the cursor, and then the Text disappears, defocuses)
Created attachment 181884 [details] N/A The attached screencast reproduces this problem; which only manifests on cocoa. Note: No, I am not pressing escape/return, it leaves the focus automatically.
Created attachment 181887 [details] Screencast reproducing it
I also saw this problem with CCombo when using org.eclipse.emf.common.ui.celleditor.ExtendedComboBoxCellEditor After focus, the combo loses focus. The workaround of waiting in a timedExec seems to work somewhat.
(In reply to comment #0) > > in doSetFocus, avoid calling setFocus. instead, create a timed display > runnable to call setFocus later. if (later <= 550 milliseconds) this doesn't > work. if (later >= 700 milliseconds) it seems to work reliably. if (later == > 600 milliseconds) it works sometimes. > > Is this perhaps related to Bug 313208 313208 deals with how we send MouseDoubleClick events. I still see this in 3.7, so that's not related.
Here's what I'm seeing: -- Click happens on the Tree. -- MouseDown is fired, so ColumnViewer activates and sets focus on the TextCellEditor. -- NSTableView determines that the cell is editable, so it tries to put up its own NSTextField for editing purposes. To do that, it first resets the first responder back to the NSTableView. -- When the first responder goes back to the NSTableView it removes it from the TextCellEditor -->> TextCellEditor is deactivated/hidden. It's not clear to me why it only happens when there's no text, but it looks like the solution is to implement tableView:shouldEditTableColumn:row to return false so Cocoa's default table editing doesn't occur.
Interestingly enough we already do this for Table but forgot to do it for Tree. The method to implement is outlineView:shouldEditTableColumn:item:
Created attachment 182088 [details] Fix Added override as described, and cleaned up the unnecessary overrides in Table and List; we never want Cocoa's cell editing behavior to occur. Waiting for 3.7 M3 declare, then I'll check it in.
Fixed > 20101101.
