12

Similar question, but not exactly the same.

table.showColumn() is helpful, but the scrolling only has the granularity of the column width. But I want a more precise control of the scroll location.

Consider the following use case. I have two tables that I know are of the same width and have the same column widths. And I want to implement some kind of a scroll synchronizer so that when the user scrolls one table (horizontally), the other table scrolls to the same location.

EDIT:

On the Eclipse forum there seems to be the same question and some working ideas, but no resolution.

EDIT: I discovered this behavior on Windows

Cœur
  • 37,241
  • 25
  • 195
  • 267
RAY
  • 6,810
  • 6
  • 40
  • 67

3 Answers3

5

The method setOrigin(x,y) in ScrolledComposite should help:

Scrolls the content so that the specified point in the content is in the top left corner. If no content has been set, nothing will occur. Negative values will be ignored. Values greater than the maximum scroll distance will result in scrolling to the end of the scrollbar.

Nobody
  • 117
  • 2
  • 12
dac2009
  • 3,521
  • 1
  • 22
  • 22
  • Interesting suggestion. Will take a look. – RAY Sep 10 '12 at 01:46
  • This worked for me. Note that the controls have to have been laid out before calling setOrigin() even if the content has been set in the ScrolledComposite. If the method is called before layout, nothing will happen. – Steven P. Nov 15 '12 at 18:56
5

I'm afraid I can't get a satisfying result in Windows Vista/7 either, but felt I was getting close.

I believe you will have to grab the Table's horizontal scroll bar by using table.getHorizontalBar(). Then, you can specify scrollbar.setSelection() to make it move to a specified position.

This is where I get stuck. Somehow, you have to notify either the Table or the ScrollBar that the value has changed. I've tried everything from update() to notifyListener(), but no dice. It seems that it is merely a matter of laying out, but layout() doesn't have any effect, either.

Incidentally, bear in mind that the ScrollBar's parent (type Scrollable) is not a ScrolledComposite like I had expected, but is actually the Table itself.

I hope this gives you some ideas and helps you find a solution. If so, please let me know, since it's bugging me now, too!

Paul Lammertsma
  • 37,593
  • 16
  • 136
  • 187
  • I don't think update() or layout() is going to work. It seems to me that setSelection() merely moves the thumb and not anything on the table. This definitely seems like a design flaw, but I wonder what we can do about it. – RAY Nov 28 '10 at 04:21
  • I agree. That's why I was trying to execute a `notifyListener()`, in the hopes that I could trick the scroll bar into updating the horizontal position of the table based upon the thumb "selection". No dice. It is noteworthy that by changing the selection, the scroll offset becomes messed up: you can then scroll beyond the boundaries of the table. Very odd indeed. Maybe post a bug report on SWT? – Paul Lammertsma Nov 28 '10 at 10:34
  • It's a bit of a long shot, but perhaps faking a mouse event at some position could do this? Shouldn't be too hard to get the size of the table and go from there. – cyber-monk Dec 15 '10 at 17:52
  • Physically clicking the scrollbar is handled on a different level than Java or SWT. Sending a mouse event will only cause a notification on the `ScrollBar`; it won't actually scroll there unless you get your hands dirty with JNI/JNA. If you're going down that street, you might as well just write the native code to update the scrollbar manually instead of trying to "click" it. – Paul Lammertsma Dec 16 '10 at 13:13
1

Having poked around in the ScrollBar source a bit, it looks like there are numerous (windows) bugs that have been overcome at one point or another. This may be another, though you didn't mention your OS, nor did Paul, so it's hard to tell.

All the "change the scroll bar position" functions end up calling SetScrollInfo which is package private. I suspect that the intention is for this to actually update things the way you want.

None of that solves your problem. Thankfully the same source also hints at a solution:

Slider.

You'd have to reimplement all the scrollbar behavior within slider, but once done, that should give you the control (har) you want. Hopefully. OTOH, you may run into exactly the same OS bug (if bug it be), and be back at square one.

At THAT point, you definitely register it as an Eclipse UI bug.

PS: Have you searched the Eclipse Bugzilla for anything similar? Poking around a bit turned up this bug related to the scroll bar being out of sync with a tree view in the Navigator (on PC Linux-Motif, but working fine in Windows). I suspect you'll find similar issues if you dig a bit more.

Mark Storer
  • 15,672
  • 3
  • 42
  • 80