Bug 148039 - tableitem.setItemHeight or tableitem.setBounds needed
Summary: tableitem.setItemHeight or tableitem.setBounds needed
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 enhancement with 10 votes (vote)
Target Milestone: ---   Edit
Assignee: Steve Northover CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 134454 (view as bug list)
Depends on:
Blocks: 195597
  Show dependency tree
 
Reported: 2006-06-21 10:17 EDT by Francis Leboutte CLA
Modified: 2021-05-02 23:20 EDT (History)
13 users (show)

See Also:


Attachments
setTreeItemHeight Workaround using Java Reflection on Win32 (992 bytes, text/x-java-source)
2010-10-31 23:42 EDT, Greg B CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francis Leboutte CLA 2006-06-21 10:17:27 EDT
Want a API like tableitem.setItemHeight or tableitem.setBounds

My example: two adjascent tables whose rows have to be
aligned. Table 1 is never updated. When a row in table 2 has its
height modified, the row height in table 2 has to be changed accordingly. 

See this thread:
http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg29375.html
Comment 1 Grant Gayed CLA 2006-06-23 17:12:34 EDT
SN, now that item heights can be specified through a MeasureItem listener, does this make sense as a more straight-forward path for clients that don't otherwise want to do custom drawing?

Note that since all Table items have a shared height, this would be Table.setItemHeight(int).
Comment 2 Steve Northover CLA 2006-06-26 10:57:01 EDT
Yes, I had thought of making it API.
Comment 3 Peter De Leuze CLA 2006-11-15 08:51:27 EST
As what I understood, is that once a row is set to a greater hight, you never can set the height of this row below the maximum value you once set.
Even if you manipulate this with Measure events... Sorry, but in my opinion it is a bug, and needs fixing.

The strange thing is that under linux (gtk) the row height DOES change when repainted. Under Windows it does not !

plz fix this... or provide a setHeight() method 
Why was this method changed from public to private in 3.2 ???
Comment 4 Steve Northover CLA 2007-03-24 11:25:50 EDT
*** Bug 134454 has been marked as a duplicate of this bug. ***
Comment 5 Boris Bokowski CLA 2007-07-09 12:28:04 EDT
Bug 195597 (which I just marked as being blocked by this) has an attached patch that works on Windows with a modified SWT where setItemHeight(int) is made public.  It seems that setItemHeight does not exist at all on GTK - is this a real limitation, or just a case where you haven't done the work for GTK yet?
Comment 6 Rohit Shetty CLA 2008-10-31 03:23:18 EDT
is there a plan to resolve this issue soon?
Comment 7 Nobody - feel free to take it CLA 2010-07-07 00:57:04 EDT
What is the status on this bug?
Comment 8 Grant Gayed CLA 2010-07-08 17:12:50 EDT
This is not currently being investigated.  It could be looked at for 3.7, but it could prove to be a significant change on some platforms, so this will be resource dependent.
Comment 9 Greg B CLA 2010-10-31 23:42:54 EDT
Created attachment 182126 [details]
setTreeItemHeight Workaround using Java Reflection on Win32

This is a simple workaround I use on Win32 for Tree#setItemHeight(int).
I prefer to use Reflection where necessary rather than patch SWT.
A similar workaround should work for Table#setItemHeight(int).
Comment 10 Michael Jastram CLA 2010-11-03 05:05:45 EDT
I have a question regarding this bug (although I fear I know the answer): Are we talking about setting the same height for all rows in the table (as is the case with Table#setItemHeight(int)), or for each row individually (as implied by the title of this issue "tableitem.setItemHeight").

My Question: While we have a workaround for setting the same height, do we have a workaround for setting different heights for individual rows?  This is the feature that I need desperately.

Interestingly, this works with GTK, but not with Windows or Mac, I documented ways to reproduce here:

http://stackoverflow.com/questions/4082082/

Again, if anybody knows about a workaround (short of using another table implementation, as suggested in bug 195597), I would be very grateful.
Comment 11 Aleksandr Kravets CLA 2013-05-09 15:44:24 EDT
Is there any work being done on this bug?
Comment 12 Michael Jastram CLA 2013-05-10 02:31:34 EDT
Hi Alexander,

(In reply to comment #11)
> Is there any work being done on this bug?

I gave up on this one long time ago (frustration) - my recommendation is to switch to a Canvas-based control like AgileGrid or NAT Tables.  That's what we did with Eclipse RMF - we just moved on.

Best,

- Michael
Comment 13 Aleksandr Kravets CLA 2013-05-14 12:51:02 EDT
Thanks Michael, I'll take a look.
Comment 14 Christoph Laeubrich CLA 2018-05-09 07:57:23 EDT
Any chance this gets resolved?
Is the problem an API can not be made cross platform? Or what is holding back resolving this?