Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Find TableColumn by Point
Find TableColumn by Point [message #559391] |
Thu, 16 September 2010 13:44 |
Daniel Krügler Messages: 853 Registered: July 2009 |
Senior Member |
|
|
I need to realize the following: I have a table with
menu and - that is important - also one a menu for the
header. If the header menu is selected (i.e. during the
SWT.MenuDetect event), I would like to determine the
associated TableColumn. I can rely on the assumption,
that it is a table *with* TableColumns. Problem is, that
TableColumn does not have a getter for it's bounds (as
TableItem has). What I currently do is the following:
1) Compute the mapped coordinates via:
Point pt = event.display.map(null, table, event.x, event.y);
2) Use the result to determine the corresponding pt result
and loop over the columns via the following algorithm
(I believe Tom Schindl published it once):
static final TableColumn findColumn(Table t, Point pt) {
int x = t.getClientArea().x;
if (pt.x >= x) {
final int idx[] = t.getColumnOrder();
final int w = t.getGridLineWidth();
for (int i = 0; i < idx.length; ++i) {
final TableColumn col = t.getColumn(idx[i]);
x += w + col.getWidth();
if (pt.x <= x) {
return col;
}
}
}
return null;
}
Problem is, that this algorithm seems to be slightly
wrong, there must be some bias during the computation.
I notice that, if my table has e.g. > 10 columns and I try
to determine the most right column. If I'm near to
the left border of the table above function will incorrectly
determine the next column to the left. Question: Is anyone
aware which additional component has to be used for proper
calculation? I have an assumption, but I'm not 100% sure:
Might it be that I need to add COLUMN_TRIM, i.e. the
platform-specific correction term found in some jface/SWT
components to correct this? If not, does anyone know the
correct formula and is willing to publish it?
Thanks & Greetings from Bremen,
Daniel Krügler
|
|
|
Re: Find TableColumn by Point [message #559397 is a reply to message #559391] |
Thu, 16 September 2010 14:15 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Can you make the assumption that the table has at least one row - this
way you could use TableItem#getBounds(int) to check.
Tom
Am 16.09.10 15:44, schrieb Daniel Krügler:
> I need to realize the following: I have a table with
> menu and - that is important - also one a menu for the
> header. If the header menu is selected (i.e. during the
> SWT.MenuDetect event), I would like to determine the
> associated TableColumn. I can rely on the assumption,
> that it is a table *with* TableColumns. Problem is, that
> TableColumn does not have a getter for it's bounds (as
> TableItem has). What I currently do is the following:
>
> 1) Compute the mapped coordinates via:
>
> Point pt = event.display.map(null, table, event.x, event.y);
>
> 2) Use the result to determine the corresponding pt result
> and loop over the columns via the following algorithm
> (I believe Tom Schindl published it once):
>
> static final TableColumn findColumn(Table t, Point pt) {
> int x = t.getClientArea().x;
> if (pt.x >= x) {
> final int idx[] = t.getColumnOrder();
> final int w = t.getGridLineWidth();
> for (int i = 0; i < idx.length; ++i) {
> final TableColumn col = t.getColumn(idx[i]);
> x += w + col.getWidth();
> if (pt.x <= x) {
> return col;
> }
> }
> }
> return null;
> }
>
> Problem is, that this algorithm seems to be slightly
> wrong, there must be some bias during the computation.
> I notice that, if my table has e.g. > 10 columns and I try
> to determine the most right column. If I'm near to
> the left border of the table above function will incorrectly
> determine the next column to the left. Question: Is anyone
> aware which additional component has to be used for proper
> calculation? I have an assumption, but I'm not 100% sure:
> Might it be that I need to add COLUMN_TRIM, i.e. the
> platform-specific correction term found in some jface/SWT
> components to correct this? If not, does anyone know the
> correct formula and is willing to publish it?
>
> Thanks & Greetings from Bremen,
>
> Daniel Krügler
>
|
|
| | | | |
Re: Find TableColumn by Point [message #559541 is a reply to message #559425] |
Fri, 17 September 2010 06:01 |
Daniel Krügler Messages: 853 Registered: July 2009 |
Senior Member |
|
|
On 16.09.2010 17:09, Tom Schindl wrote:
> hm did you try Scrollable#getVerticalBar()#getSize() to get the width of
> the scrollbar to subtract?
Thanks for this hint Tom!
Unfortunately this value does not help, because it reflects the fixed
*width* of the bar. What I need (and where I currently don't know how
to get this information) is the following:
It seems that the calculation error occurs, if you have an active
horizontal scroll bar and if you are attempting to get the
aforementioned point coordinates, if the "virtual" table size
is larger than the visual one *and* if you are at the rhs of this
area attempting to open the context menu. The above coordinates
evaluate to the visual one, but these give you a completely wrong
base of calculation because they don't start at table column 0,
but instead at the table column which is currently at the border of
this visual left end of the table (The invisible part contains the rest).
Did I make my case clear or should I provide an image for better
clarification?
Thanks very much,
- Daniel
> Tom
>
> Am 16.09.10 16:37, schrieb Daniel Krügler:
>> On 16.09.2010 16:30, Tom Schindl wrote:
>>> I think the TableColumnLayout does this to some extend.
>>
>> I checked this class and its base class, but unfortunately
>> it doesn't seem to do that job. It is correct that it uses
>> COLUMN_TRIM, but this turned out not to be the actual error
>> source. I also believe that TableColumnLayout doesn't need
>> to do this calculation including the scroll bar.
>>
>> Any further ideas?
>>
>> Thanks,
>>
>> - Daniel
>
|
|
| |
Re: Find TableColumn by Point [message #559754 is a reply to message #559742] |
Fri, 17 September 2010 21:24 |
|
It works for me. After adding HorizontalScrollBar's selection Position to event.x. It works fine and identifies right column click.
Here is the code snippet:
table.addListener(SWT.MenuDetect, new Listener(){
public void handleEvent(Event event){
Point point = Display.getCurrent().map(null, table, new Point(event.x, event.y));
Rectangle clientArea = table.getClientArea();
boolean header = clientArea.y <= point.y && point.y < (clientArea.y + table.getHeaderHeight());
if(header){
TableColumn column = findColumn(table, point);
logger.info(" @@@@ Header Click Identified... Should Open Filter Dialog for Column: " + column.getText());
table.setMenu(createHeaderMenu(column.getText()));
}else {
logger.info(" @@@@ Table Click Identified ... Should Open Right Click Menu...");
table.setMenu(createRightClickMenu(null));
}
}
});
Thanks Daniel Again by providing a partial solution. It really helped me to quickly close this issue.
Jatin Vasa
|
|
|
Re: Find TableColumn by Point [message #626215 is a reply to message #559391] |
Wed, 22 September 2010 12:56 |
Daniel Krügler Messages: 853 Registered: July 2009 |
Senior Member |
|
|
On 16.09.2010 15:44, Daniel Krügler wrote:
> I need to realize the following: I have a table with
> menu and - that is important - also one a menu for the
> header. If the header menu is selected (i.e. during the
> SWT.MenuDetect event), I would like to determine the
> associated TableColumn. I can rely on the assumption,
> that it is a table *with* TableColumns. Problem is, that
> TableColumn does not have a getter for it's bounds (as
> TableItem has).
[...]
After getting some help from the javanb pages:
http://book.javanb.com/swt-the-standard-widget-toolkit/ch05l ev1sec6.html
I found a solution which seems to work and which seems even
to be portable, see below. The solution is to evaluate the
*selection* of the horizontal scrollbar - if existing.
Unfortunatly the documentation of this method is not very
helpful, but it seems that the return value corresponds to
a number of *pixel* and - at least on Windows - this value
corresponds exactly to the width of the invisible area
occupied to the "left". I also noted that adding the grid-line-
width is wrong and need to be removed. The final solution
so far:
public static final TableColumn findColumn(Table t, Point pt) {
final ScrollBar hb = t.getHorizontalBar();
final int offs = hb != null ? hb.getSelection() : 0;
final Rectangle area = t.getClientArea();
final int x0 = area.x + offs;
final int xp = pt.x + offs;
if (xp >= x0) {
final int idx[] = t.getColumnOrder();
int x = 0;
for (int i = 0; i < idx.length; ++i) {
final TableColumn col = t.getColumn(idx[i]);
final int xNext = x + col.getWidth();
if (xp >= x && xp < xNext) {
return col;
}
x = xNext;
}
}
return null;
}
I would be happy, if I get feedback from those that find
more glitches in this algorithm.
HTH && Greetings from Bremen,
Daniel Krügler
|
|
|
Goto Forum:
Current Time: Fri Sep 20 11:47:33 GMT 2024
Powered by FUDForum. Page generated in 0.04528 seconds
|