The quieter you are, the more you are able to hear.
Kemal Sokolovic wrote:1)
You can use underlying Document of your component, that contains insertString method.
2)
The quieter you are, the more you are able to hear.
Michael Dunn wrote:after the code to append new text, add this line
textPane.setCaretPosition(textPane.getDocument().getLength());
not tried it on a textPane, but that works fine for other text components
Kemal Sokolovic wrote:Well, I guess I didn't test it well. I put a JScrollPane with text to append, and a button at the bottom of frame that scrolls down the pane with code that I showed you in the previous post. And it worked! On the other hand, when I put the same code after the one that appends the text, it doesn't work.
So I tried to tweak it out a little, until we wait for someone else to tell us about that strange behavior, I'm intrigued now.
Perhaps not the best solution, but it works.
The quieter you are, the more you are able to hear.
Kemal Sokolovic wrote:The last code I gave you works well for your purpose, just invoke scrollToBottom() after you append text at the end of the pane.
The quieter you are, the more you are able to hear.
In my program, the scroll code is ONLY called immediately after changing the content of the JTextPane. You're saying the code works just fine if it's run alone? That IS weird! Not that I'm at all surprised. Yay Java Swing!
Kemal Sokolovic wrote:Since it works well at me, I would suggest you debug and check if that if evaluates to true (the one in which you invoke scrollToBottom()). You maybe don't even need to perform all those checks, because given method will work properly in any case.
Isn't that the order I'm currently doing it in?Tony Docherty wrote:The problem is once you add something to the text pane the size of the panel changes and hence the size of the scrollbar. You need to check if the scrollbar is at the bottom before you add anything else to the pane, then add the text and then move the scroll bar if required.
Tony Docherty wrote:
This is not correct because the value to set to put the slider button is at the bottom of the scrollbar is the scrollbar's maximum value less it's extent (the size of the slider button).
Does this do what you want?
Note I needed to add the scroll bar slider button repositioning code to the event queue so it happens at a future time or the repositioning is overwritten by the default action of adding text to the text pane.
I have seen that eventQueue code in some other places, but it has always seemed iffy to me
not to mention, the "run later" method seems sort of hack-ish
Tony Docherty wrote:
I have seen that eventQueue code in some other places, but it has always seemed iffy to me
If that seems iffy you need to read a tutorial on how Swing works.
Tony Docherty wrote:
not to mention, the "run later" method seems sort of hack-ish
It's a good job I have a sense of humour, some people would get offended by having their attempt to help described as "iffy" and "hack-ish".
BTW Did you run the code I supplied and does it work the way you want?
Maybe I don't fully understand what your problem is then because once the scroll bar slider is moved to the bottom it stays there, at least on my system it does. When you say after some time it fails at approximately what line number does this tends to happen as I've run it multiple times adding thousands of lines each time and not seen any issues.But seriously... uh, nope, I regret to inform you this solution has the same issue as the previous one - It appears to work for a few times at first (and you might even have to "kick it into place" at first when the scroll bar first appears) but after some time, a gap appears between the scroll bar and the bottom,
Tony Docherty wrote:
Maybe I don't fully understand what your problem is then because once the scroll bar slider is moved to the bottom it stays there, at least on my system it does. When you say after some time it fails at approximately what line number does this tends to happen as I've run it multiple times adding thousands of lines each time and not seen any issues.But seriously... uh, nope, I regret to inform you this solution has the same issue as the previous one - It appears to work for a few times at first (and you might even have to "kick it into place" at first when the scroll bar first appears) but after some time, a gap appears between the scroll bar and the bottom,
BTW Yes you will have to move the slider to the bottom when the scrollbar first appears as it doesn't start at the maximum position although you could add a listener to handle this situation.
Tony Docherty wrote:All calls to Swing methods must be made on the Event Dispatch Thread (EDT) unless the method is marked as being thread safe. Inserting text into a Document object is not thread safe and therefore must be called on the EDT which you are not doing.
The simplest solution to test if this works for your code is to wrap the call in ChatManager to gui.updateChat() in a Runnable object and pass that to the EventQueue. ie:
Yes I'm afraid it's another one of those
To clarify, the methods that Swing uses INHERENTLY go against proper thread management (I'm guessing Swing classes use their own threads, throwing any attempt to sync them out the window?)
Tony Docherty wrote:
To clarify, the methods that Swing uses INHERENTLY go against proper thread management (I'm guessing Swing classes use their own threads, throwing any attempt to sync them out the window?)
Not quite. Swing is single threaded and that thread is the EDT. For example when you click a button the event is dispatched on the EDT. Therefore, to ensure calls to Swing methods are only ever run on a single thread you enqueue tasks to the EventQueue and let the EDT do the work when it is next free.
Some methods are marked as thread safe and in these cases if the calling thread is the EDT it just does the work otherwise the call is enqueued to the EventQueue.
Note: there are 2 ways of enqueueing tasks to the EventQueue: invokeLater() and invokeAndWait().
I must admit, I completely misunderstood the purpose of the EventQueue before, but I think it makes sense now
Regardless of when, I'll be sure to report on the results.
Tony Docherty wrote:
I must admit, I completely misunderstood the purpose of the EventQueue before, but I think it makes sense now
So are you saying you no longer think my code is quite so iffy and hackish
Regardless of when, I'll be sure to report on the results.
I look forward to it.
I had apparently made a lot more code-breaking changes in my program then I thought.
I am going down to the lab. Do NOT let anyone in. Not even this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|