Bug 125827 - [CellEditors] ComboBoxCellEditor fires #modify too late.
Summary: [CellEditors] ComboBoxCellEditor fires #modify too late.
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2006-01-31 09:07 EST by James Leotta CLA
Modified: 2020-01-16 17:44 EST (History)
8 users (show)

See Also:


Attachments
My proposition is to add "part.getControl().forceFocus();" line (17.45 KB, text/java)
2006-05-12 12:26 EDT, Krzysztof Michalski CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Leotta CLA 2006-01-31 09:07:26 EST
I have a editor part that contains a TableViewer with a ComboBoxCellEditor.  When I modify the cell in the table and directly close the editor the modify# method in the CellModifier is called after the call to isDirty() by the editor.  This creates a false state for the editor and the user is never prompted to save changes.
Comment 1 Krzysztof Michalski CLA 2006-05-12 12:26:42 EDT
Created attachment 41328 [details]
My proposition is to add "part.getControl().forceFocus();"  line

The solution is to put: 

case TabFolderEvent.EVENT_CLOSE: {
  IPresentablePart part = folder.getPartForTab(e.tab);
  if (part != null) {
    part.getControl().forceFocus(); 
    getSite().close(new IPresentablePart[] { part });
  }
  break;
}

instead of

case TabFolderEvent.EVENT_CLOSE: {
  IPresentablePart part = folder.getPartForTab(e.tab);
  if (part != null) {
    getSite().close(new IPresentablePart[] { part });
  }
  break;
}

in the internal implementation of class TabFolderListener in org.eclipse.ui.internal.presentations.util.TabbedStackPresentation
Comment 2 Gunnar Wagenknecht CLA 2006-05-12 12:31:12 EDT
(In reply to comment #1)
> My proposition is to add "part.getControl().forceFocus();"  line

Wouldn't this activate a part if you want to close it without bringing it to front?
Comment 3 Krzysztof Michalski CLA 2006-05-12 13:18:22 EDT
I checked it and everything seems ok. 
Comment 4 Mike Wilson CLA 2006-05-12 13:21:04 EDT
When you say "ok", do you mean "yes, it activates it and that doesn't cause problems" or "no, it doesn't activate it anyway"?
Comment 5 Krzysztof Michalski CLA 2006-05-12 13:26:09 EDT
If "activate" equals "bringing to front", it doesn't activate the part.
Comment 6 Tod Creasey CLA 2006-05-12 14:05:42 EDT
The forceFocus is a call to SWT to make it the focus widget but I would be concerned about doing that to a widget that is not in the front - I could easily forsee a situation where focus is given to an invisible widget and the user thinks nothing has focus. 

This may be working on XP but I could see other OSs handling this situation differently.
Comment 7 Krzysztof Michalski CLA 2006-05-15 11:23:21 EDT
I add one change to my solution as below:
case TabFolderEvent.EVENT_CLOSE: {
  IPresentablePart part = folder.getPartForTab(e.tab);
  if (part != null) {
    Control control = part.getControl();
    if (control != null) control.forceFocus() ;
    getSite().close(new IPresentablePart[] { part });
  }
I add check: if control is not null. It's connected with late loading of Editor.

I check my solution on Linux with GTK. I can close hidden editor (not front) and focus not change. I try close hidden and dirty editors and when Eclipse asked me about saving. I check on click cancel, no and yes case. In all this cases focus not change. I think everything works good. 
Could You check it and give me a feedback with Your opinion.
Comment 8 Eric Moffatt CLA 2006-07-05 14:47:55 EDT
Krsysztof, could you make a patch out of your suggestion to make it easier to review?

Thanks..

Comment 9 Henno Vermeulen CLA 2013-01-18 05:09:20 EST
I think this is a more general problem that may also exist with other cell editors and other actions e.g. with a save command. See bug 242231.
Comment 10 Eclipse Genie CLA 2020-01-16 17:44:28 EST
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.