Home » Eclipse Projects » Remote Application Platform (RAP) » TableViewer / TableEditor problem, bug?(on scrolling, the content with the editors (controls) overlaps tablea column header)
TableViewer / TableEditor problem, bug? [message #893045] |
Mon, 02 July 2012 12:20  |
Eclipse User |
|
|
|
Hi all,
I used the concept of TableViewer together with TabelEditors to place controls inside a tableviewerCell. It actually works perfect(I worked according to the eclipse example), but whenever the table is scrolled, the cells with controls (TableEditor) overlap the header (Columnname) of the table. has anybody faced the same problem or just knows why this happens?
Best regards,
R
|
|
|
Re: TableViewer / TableEditor problem, bug? [message #893229 is a reply to message #893045] |
Tue, 03 July 2012 09:49   |
Eclipse User |
|
|
|
Hi,
I can reproduce the issue with Controls Demo -> TableViewer tab and RAP
from Git master. Would you mind to open a bugzilla about it?
Thanks,
Ivan
On 7/2/2012 3:20 PM, r k wrote:
> Hi all,
> I used the concept of TableViewer together with TabelEditors to place
> controls inside a tableviewerCell. It actually works perfect(I worked
> according to the eclipse example), but whenever the table is scrolled,
> the cells with controls (TableEditor) overlap the header (Columnname)
> of the table. has anybody faced the same problem or just knows why
> this happens?
>
> Best regards, R
--
Ivan Furnadjiev
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
| |
Re: TableViewer / TableEditor problem, bug? [message #893342 is a reply to message #893234] |
Tue, 03 July 2012 16:00   |
Eclipse User |
|
|
|
Hey Ivan,
i think there is another bug, that if you scroll to the last object in the list, you can still scroll one row further, so that the controls are shifted one row further and the last control is then in an "empty row". The command table.getItemCount()always shows the correct amount of entries, so that its not a workaround to just delete the last row. Even the scrollbar shows a small space to show that ist possible to scroll a bit further into this empty row.
Can u confirm that?
Best regards,
Ron
|
|
|
Re: TableViewer / TableEditor problem, bug? [message #893374 is a reply to message #893342] |
Tue, 03 July 2012 18:13   |
Eclipse User |
|
|
|
Hi,
if I remember correctly the the empty row after the last item is there
by design.
Best,
Ivan
On 7/3/2012 7:00 PM, r k wrote:
> Hey Ivan,
>
> i think there is another bug, that if you scroll to the last object in
> the list, you can still scroll one row further, so that the controls
> are shifted one row further and the last control is then in an "empty
> row". The command table.getItemCount()always shows the correct amount
> of entries, so that its not a workaround to just delete the last row.
> Even the scrollbar shows a small space to show that ist possible to
> scroll a bit further into this empty row.
> Can u confirm that?
>
> Best regards, Ron
--
Ivan Furnadjiev
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
| |
Re: TableViewer / TableEditor problem, bug? [message #893677 is a reply to message #893437] |
Thu, 05 July 2012 08:36  |
Eclipse User |
|
|
|
Hi,
the vertical scrolling in Table/Tree is based on rows not pixels.
Depends on your Tree/Table size the empty space after the last item
could be zero or almost a complete row height. There is no way to make
it always zero. If you find a bug, please open a bugzilla with a
self-running snippet/project that demonstrate the issue.
Thanks,
Ivan
On 7/4/2012 10:52 AM, r k wrote:
> But in de cotnrol version it causes a shioft of one row. Any idea hw
> to workaround the last row?
>
> Thanks, Ron
--
Ivan Furnadjiev
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
Goto Forum:
Current Time: Wed Feb 19 22:44:12 GMT 2025
Powered by FUDForum. Page generated in 0.04102 seconds
|