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

Yes, open a PR - doing what you want should not be so difficult.  Of your
suggestions - making applyEditorValue() public is reasonable(i.e., basically
your initial finishEditing request).

internalRefresh is pretty heavy-weight.  What problems did you run into that
caused you to use this method?  I do not think that this should be made
public.

Could you hack up the code and make applyEditorValue() public and see if
that would sufficiently solve your problem?  It'd be useful to know as part
of how to handle the PR.

Lynne

"Paul T. Keyser" <rolarenfan@xxxxxxxxx> wrote in message
news:3D80FBD2.6D85FF19@xxxxxxxxxxxx
> 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).
> > > >
> > >
>