Creating a left-hand margin for a JEditorPane text box - java

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.

Related

JComboBox: arrow-button should be shown at any time

If a JComboBox is not selected, the arrow-button on the right is not shown. This leads to the fact that a combo-box cannot be distinguished from a normal textfield.
The question is now: how is it possible to show the arrow-button permanently? I alrady came across BasicComboBoxUI.createArrowButton() etc., but I did not find out the mechanism of hiding / showing the arrow-button.
Can anyoune give me a hint how to show the arrow-button permanently ?
Can you add below code as first line in your main method.
Toolkit.getDefaultToolkit().setDesktopProperty("win.xpstyle.themeActive",Boolean.FALSE);
and then check your program.
sorry for the inconvenience. Everything is clear now. In have been told that we use a special framework which changes the behaviour. This information would have been useful if given to me earlier... :-(

How do I make one component visible in more than one pane in a JTabbedPane?

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.

+Android Webview - how to autoscroll a page?

I'd like to open a html-page in a webview and make it auto-scroll downwards automatically in accordance with an interval set through a timer.
Although below example is for desktop, this link should give you an idea what I want to achieve (enable autoscrolling in the upper right part of the page):
example
First I thought about opening a webpage and then use some kind of code which would simulate/trigger DPAD-down (or Arrow-down). In Windows Mobile, I believe there was something called SendKeys but I couldn't find something similar in the Android-SDK (except for a test-SDK which I doubt I could use for publishing my app in AndroidMarket) so I guess the way mentioned above is not possible.
Another solution could perhaps be a java-script but the webpages are not created by me so I can't insert any anchor.
However, I noted that Webview has some methods called PageDown (and PageUp) which could also be a solution but I am afraid a PageDown would be too much for scrolling the way I want. I want the scrolling to be slow and smooth, more like a line at a time.
Do you have any ideas how I could implement this? I'd really appreciate your help.
You could try using,
View.scrollBy(int x, int y) to scroll the WebView.Use:
computeVerticalScrollOffset(),
computeVerticalScrollExtent() computeVerticalScrollRange() to calculate a maximum y value.

Programmatically Scroll an SWT Table horizontally

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.

Drag and drop with an image

I need to create a drag and drop system in swing where an image of the thing being dragged is attached to the cursor during the drag. In theory this is achieveable with
public Icon TransferHandler.getVisualRepresentation(Transferable t)
but there appears to be a long standing bug (here) that means this method is never called. I know I can do it by implementing my own DnD system with DragSource etc., but does anyone know of an easier workround that will get me what I need?
The method TransferHandler.getVisualRepresentation wasn't supported in java 1.4, I'm not sure if or when it was fixed. To test whether it works in a current version you could adapt this example
In the end I used the old style drag-and-drop to implement what I wanted. However I have no reason to think abrightwell's solution wouldn't work just as well - this was just the best way at the time.
You could Try putting the image on a Jlabel (in the draggesture recognizer)and set its bounds, in the droptargetListener dragover method. Alternately, hows about implementing a Mouse listener (I've not tested this latter method).
I have used the "work around" suggested towards the bottom of the bug report you have listed. It worked well enough for me. Granted I was using this with Mac OS X so I have no idea whether Winderz will support it. It would be nice if they would at least fix it to work like they intended and simply document where it will and won't work... oh well. Good Luck.

Categories