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
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.
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!
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.
Related
I was wondering if there was a way to make one component (in this case a JPanel) visible in more than one of the tabs.
I have a simple JFrame which is completely filled with a JTabbedPane. Each tab has a slightly different function, which is why they're in different tabs. However, they each output the same type of information. I was wondering if there was a way to make it so the same output panel could be seen in all the tabs, without having to create one panel for each tab.
I realize that it is impossible to add one component multiple times (and have it display independently each time), which is why I'm not optimistic about this being possible, however if it is, it would make my code much cleaner. In the case that this is not possible, I am completely open to alternate suggestions that achieve a similar result. I am in the very beginning of my project, so it won't be too difficult to change things.
This image gives a rough idea of what I'm trying to make it look like:
I have searched around for anyone dealing with this issue, however I have had little luck finding anything relevant. If I missed something, I apologize for wasting your time.
I may need to create my own JScrollPane subclass. I've looked at the JScrollPane and ScrollPaneLayout source and believe I understand how it works. However, I can't see where the scrollbar(s) (when present) are "connected to" the viewport. In other words, I was expecting to see the viewport listening to the scrollbar to determine the displayed view coordinates, but find nothing about that. Will someone explain and/or point to me to the code that is doing this?
The last thing I thought to examine were the listeners on the JScrollPane. Doing so led me to javax.swing.plaf.basic.BasicScrollPaneUI.Handler, which is where all the "wiring" happens. So that's the answer to the original question - but it points out an unfortunate reality: if I attempt to subclass JScrollPane to work as I intend, it seems unlikely that I'll be able to do so without breaking PLaF (with my current understanding of PLaF).
Edit: I found this link to be helpful in understanding swing.plaf.*, although it's quite old: http://www.oracle.com/technetwork/java/architecture-142923.html
I have a graphical editor written with GEF. In this editor it's possible to drag and drop elements around and create connection by dragging and dropping on specific anchor points.
Everything works fine, except that the diagram does not automatically scroll when the user drags stuff around.
I would expect the diagram to scroll automatically when the user reaches the side of it while dragging something.
Is such a feature supported by GEF? Which class/setter should be called to enable it?
If it's not directly supported, how to proceed to achieve it?
It's been a while since I last fiddled with GEF.
Does drag and drop not work at all or just in the direction of negative coordinates?
What Layout are you using?
IIRC, there were different layouts with one of them (FreeForm?) supporting negative coordinates, so if you just have trouble with negative coords, you could try to change the Layout.
Here is an example of a Scrolling Graphical editor (the author says ;)) which might give you a good hint.
And there is a class named org.eclipse.gef.ui.parts.ScrollingGraphicalViewer that might help, too.
Only hints, though, since I don't know your code.
First step is to make your canvas scrollable. This is explained in this book, pages 96 - 101.
Assuming you are already drawing your figures on a FigureCanvas and you're using FreeformFigures and FreeformLayer, you can do the following:
Add a MouseMoveListener on your Figure in its EditPart. Each time a drag is detected, in the mouseDragEvent method, reveal your figure with getViewer().reveal(EditPart.this).
This will cause your Figure to always be constantly revealed when it's being dragged.
I've got a problem, that swing components in different parts of program have sometimes wrong background. For example this or this.
As I mentioned, the bug is not permanent and it can appear in one place one time and never after. But still there are some places, where I can randomly reproduce it. Unfortunately, I don't see any solutions.
Has anyone some ideas how can I fix it?
If you set your components to non-opaque (I think the call is setOpaque(false)), that will let the background colour of the component that it is on top of show through.
in addition to what Paul said, there's the question if you use self made components.
Such components should take care of their complete occupied region (or at least the invalidated regions) in the paint callback. An error seen quite often that leads to strange artifacts when moving or resizing is that only "important" parts are repainted, for example a string to be shown, without drawing the background.
In this case, anything previously blitted ther will show through.
Edit - in short, what I'm looking for is a reliable way to add a left margin to a JEditorPane (read on for the issues I'm having if you'd like).
I am trying to style some text in a JEditorPane, and have been fairly successful. The only problem I'm facing is that it seems impossible to create a margin.
Basically, I've extended PlainView and overridden the drawUnselectedText method. For now I just have it coloring the text red and changing the font. I've also overridden the drawSelectedText method to color the text.
This works consistently, whether text is selected or not, regardless of cursor position etc. - as long as I don't have a margin set.
However if I set a margin for the JEditorPane, the JEditorPane only works most of the time. The only case where it doesn't work is when a selection is made starting at the left-most character of any line. In that case, the margin is simply ignored and the selected text appears to the far left of the JEditorPane.
I know this is a pretty specific issue that most other people probably haven't experienced, and I have found nothing on the net about this, but I'm hoping someone here will have a solution.
Any ideas? Even anything that would allow me to set a margin using some other method than what I'm doing would be extremely helpful.
I gave up on finding an elegant solution to this problem. Basically I created a hack which tests whether or not the conditions exist where the bug will occur (selection from left, etc), and if they do it adjusts the rendering of the text.
I really don't like hacks as they are often bad for portability and maintainability, but this seems to work, so I suppose I'll abstract it away and hope it doesn't break anything.
In any case, it's working which is the key point. I didn't receive any answers, but I'm sure there are some people who at least tried to think of something, so thanks :)
Btw - if someone can come up with an elegant solution I will still accept that instead of my own answer (I can't anyways for two days).
Edit: This is one reason I like Java. Hacks are less likely to cause portability issues - even though this is related to rendering (it works through interaction with a Graphics object), it should still work on any OS.