[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.platform.rcp] Re: [jface.viewers] May CellLabelProvider.update be called by clients?
|
Hi,
I'm not sure I got this completely. Are you asking whether you should
call CellLabelProvider.update() your own?
I don't think this should be done but rather you should force the
table/tree to redraw the "dirty" parts. Using
Table/Tree#redraw(int,int,int,int,boolean).
Tom
Daniel Krügler schrieb:
> Hello,
>
> in a recent thread
>
> "[jface.viewers] How do discriminate active and non-active links
> in ColumnViewer?"
>
> a HyperlinkColumnLabelProvider was demonstrated to by easily
> implementable on top of the user-drawing ColumnLabelProvider API of
> jface. A remaining problem was that I additionally wanted to simulate
> the color-changes of an activated hyper-link. Thanks to Tom Schindl's
> excellent hints (again) I started with an implementation, but I'm now at
> a point where I'm not sure whether I'm subverting the official API of
> CellLabelProvider and ViewerCell or not. My current idea is *not* to
> invoke Viewer.update(...) with the corresponding object of the activated
> link, but to memorize a ViewerCell of the most recent activated
> hyperlink (we find a similar apporach in e.g. the SWTFocusCellManager).
> If a mouse-move event enters a *new* cell, I need to "deactivate" the
> last one and to activate the new on, of course. It seems tempting to
> directly use the update method of the HyperlinkColumnLabelProvider with
> this previous ViewerCell (if it's item is not disposed yet) as argument
> and similarly to use the same method again for the newly entered
> hyperlink cell. Current experiments indicate that this seems "to work".
>
> My question is: Is this a feasible usage of the CellLabelProvider API?
> I have not seen any contradictory documentation but I'm a bit uncertain,
> because I could not find any public usage of this method except for
> the viewer, which also does some additional work.
>
> Even if turns out not to be an API abuse, does anyone have an idea of a
> more reliable of efficient way to realize that?
>
> Thanks & Greetings from Bremen,
>
> Daniel Krügler