[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools] Re: Howto get ICellModifier to *finish* (not cancel) editing?

Indeed, I wound up iterating through the CellEditor[] and checking isActivated()
on each non-null CellEditor to find the current column index; but to get the
"current" CellEditor to do all the right things, I just decided to use the
internalRefresh() method, to which I gained access by subclassing TableViewer.
Can you see anything wrong with that?  If not, wouldn't that make a good
request-for-feature?  ("make TableViewer's internalRefresh() or at least a call
to TableViewerImpl's applyEditorValue() public")

Thanks,
Paul K

Lynne Kues wrote:

> Okay, I looked some more - getCellEditors() returns all cell editors - not
> active ones - my browsing mistake...
>
> Anyway, cell editors are set in column order, right?  And CellEditor has API
> for whether or not it is activated, right?  So you could ascertain the
> column.
>
> You also mentioned ending editing on enter, looks like you could use
> ICellEditorListener for that.
>
> Note, I haven't tested any of this out...
>
> "Paul T. Keyser" <rolarenfan@xxxxxxxxx> wrote in message
> news:3D80D685.B5D5CD9A@xxxxxxxxxxxx
> > Um, er, I don't think so?  For example, in a TableViewer of say seven
> columns,
> > in which, say column 3 is being edited, the API docs suggest that that
> method
> > will return a CellModifier[] of length 7; looking at the code in
> TableViewer and
> > TableViewerImpl suggests the same thing.  That'd be ok -- *if* I had a way
> of
> > finding from TableViewer or from ICellModifier the index (3) of the column
> > currently being edited -- which I see no way to do.
> >
> > I also notice a method in TableViewerImpl called applyEditorValue() which
> does
> > exactly what I want, except that the only public or protected methods of
> > TableViewer that call it are not quite appropriate.  It does look like I
> could,
> > e.g., call TableViewer.internalRefresh(null) and that would call
> > applyEditorValue() -- and do some other stuff that I can only hope is not
> wrong.
> >
> > Still puzzled,
> > Paul K
> >
> > Lynne Kues wrote:
> >
> > > I think TableViewer.getCellEditors() will return the active cell
> editor(s).
> > >
> >