Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 10687

Summary:	[Cell Editors] CellEditor class is hard to use outside of Tables
Product:	[Eclipse Project] Platform	Reporter:	Randy Hudson <hudsonr>
Component:	UI	Assignee:	Andrew Irvine <airvine>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	P2	CC:	n.a.edgar
Version:	2.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:
Bug Depends on:	15923
Bug Blocks:

Description Randy Hudson

2002-03-04 11:57:37 EST

I am trying to reuse CellEditor's in GEF.  Motivation to do this is based on 
the validation framework and listener model (i.e., when to commit the change) 
that is already in place.  Also, there is the accelerator problem with nested 
controls that CellEditor has been programmed to handle (Undo/Redo).

1)
I expect CellEditor to be analogous to JFace's Window class.  It should be a 
Control factory/manager.  I should be able to ask it to repeatedly construct 
the SWT control and tear it down.  As a framework, we are trying to allow 
people to configure something by providing a CellEditor.  currently, they must 
provide the class, which we then instrospect for a Constructor that takes a 
Composite.

2)
I also talked with Nick about putting border around CellEditors.  CEs currently 
assume that they are inside a Table that is drawing grid lines.  In GEF this 
isn't the case.  Currently it is impossible to set the STYLE of the control 
that gets created.  We need to be able to do this as well.  I copied 
TextCellEditor and set the Style bit to BORDER, but this produced a sunken 
border.  I want a single black line border.  Can this be done?

Comment 1 Nick Edgar

2002-03-06 09:23:59 EST

The TableViewers expect the cell editors to be created eagerly, then manage 
their visibility using Control.setVisibility.
Can you do it this way?

Comment 2 Randy Hudson

2002-03-06 10:18:35 EST

I can't think of any reason why I would want to create hundreds of Text 
controls eagerly.  Certainly there is no performance problem in creating a 
CellEditor.  This will create needless listeners on the Figures that own the 
cell editors, slow down scrolling performance (our scrolling is not native), 
and will complicate the code.

I looked at TableEditor class.  It seems to only hold onto a single TableItem.  
And TableViewer only holds onto a single TableEditor instance.  I don't see 
where multiple CellEditors are managed.

There is also a problem of lifetime management.  Controls must be disposed, and 
I am doing so when the change has been applied.  I don't want a mechanism to 
dispose the controls at a later time.

Comment 3 Kevin Haaland

2002-03-06 20:25:06 EST

The priority on this defect report does not look right to me.

Comment 4 Nick Edgar

2002-05-26 14:52:22 EDT

Bug 15923 covers the need for style bits.

Comment 5 Andrew Irvine

2002-11-22 11:14:12 EST

Fix submitted to 20021122 build.

Three constructors on cell editors
CellEditor
CellEditor(Composite)
CellEditor(Composite, int (style))

New methods
setStyle(style)
getStyle()
create(composite)

UI subclasses of celleditors updated appropriately.