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

"Paul T. Keyser" <rolarenfan@xxxxxxxxx> wrote in message
news:3D81F5A1.35E6011E@xxxxxxxxxxxx
> 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?

You could just import external plugin (org.eclipse.ui) with its source and
then change the appropriate *.java files (brute force, but "little thought"
approach).  I was assuming that you already have the external plugins that
are required to Run As --> Runtime Workbench loaded in your workspace - no?

Anyway, it would be worthwhile to see if that works sufficiently for you or
if there are other gotchas.  If it's too much hassle, don't bother with it.

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

Sorry, PR is old terminology - open a bug report in bugzilla.

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