[news.eclipse.tools] Re: Howto get ICellModifier to *finish* (not cancel

["Paul T. Keyser" <rolarenfan@xxxxxxxxx>]

a) I used internalRefresh() simply because TableViewer's datamember
"tableViewerImpl" is private, so even subclassing TableViewer wouldn't have
allowed me to call tableViewerImpl.applyEditorValue(), and so I needed a method
of TableViewer that was either protected or public and which called
tableViewerImpl.applyEditorValue() -- the only two appear to be
internalRefresh() and handleMouseDown(); I guesstimated that I would get fewer
sideeffects by subclassing TableViewer and calling internalRefresh() rather than
by creating a MouseEvent and calling handleMouseDown().

b) "Could you hack up the code and make applyEditorValue() public" -- that would
mean copying into my local project all the classes from jface.viewers that are
needed to get TableViewer to work (which might mean just TableViewer and
TableViewerImpl, but I won't be able to tell until I try), right?

c) are PR's handled in bugzilla just like bugs or is there some other interface?

Paul K

Lynne Kues wrote:

> 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).
> > > > >
> > > >
> >