File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Swing / AWT / SWT and the fly likes Event Listener for JTextArea? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Event Listener for JTextArea?" Watch "Event Listener for JTextArea?" New topic
Author

Event Listener for JTextArea?

Fred Hamilton
Ranch Hand

Joined: May 13, 2009
Posts: 679
In my application, there is a GUI class that includes a JTextArea. There is another class of the application, that runs in its own thread, that will write to this JTextArea. I wish to have the class that contains the GUI respond according to what this other class writes to the JTextArea.

I do not wish to have a thread in my GUI class to monitor for changes to the JTextArea, so I thought about some kind of an event listener. The only one I could find that seemed suitable was a CaretListener. But, the caret listener is supposed to react to changes in the caret. But what if the caret position does not change? the contents of the string that the text area is set to may change, but the length will probably not change, ergo, no change to the caret right?

I realize there are other ways for info to be passed between classes, but there are good reasons why I want to do it this way.


edited to correct spelling
Michael Dunn
Ranch Hand

Joined: Jun 09, 2003
Posts: 4632
> I do not wish to have a thread in my GUI class to monitor for changes to the JTextArea

even though you do not want it, a DocumentListener sounds like it would do the job,
having your code in insertUpdate(), leaving changeUpdate() and removeUpdate() to do nothing
Fred Hamilton
Ranch Hand

Joined: May 13, 2009
Posts: 679
Michael Dunn wrote:> I do not wish to have a thread in my GUI class to monitor for changes to the JTextArea

even though you do not want it, a DocumentListener sounds like it would do the job,
having your code in insertUpdate(), leaving changeUpdate() and removeUpdate() to do nothing


no, no problem with document listener, just didn't want to deal with threads in this class.

I forgot about Document Listeners. I've used them in the past, so I don't see a problem. I'll give it a go and let you know in a day or two how it goes. Thanks.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18992
    
    8

Note also that a DocumentListener attached to the JTextArea will be notified of all changes to the component, not just those changes made by your other class. If that isn't what you want -- if you only want to act on changes made by the other class and not on changes made by the user typing in the field -- then you should change your design so that you make something which listens to the other class.
Fred Hamilton
Ranch Hand

Joined: May 13, 2009
Posts: 679
Paul Clapham wrote:Note also that a DocumentListener attached to the JTextArea will be notified of all changes to the component, not just those changes made by your other class. If that isn't what you want -- if you only want to act on changes made by the other class and not on changes made by the user typing in the field -- then you should change your design so that you make something which listens to the other class.


Yeah I was wondering about that. I'll have to come up with something. Ultimately the two classes will be totally independant, and communicating via some kind of I/O stream. But I am weak in I/O streams, so the DocListener is like a temporary compromise, that allows me to proceed with application development without waiting till I master I/O. I just wanted to try something different than methods calling back and forth. Anyways, it's not a showstopper. basic method calls will also serve the purpose in the short term.

thanks.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18992
    
    8

I don't think that communicating via an I/O stream is the best design.

For one thing, as soon as you decide you need to have two objects getting data from a single information source, you're stuck because they can't both read the same data from the stream. That's what just happened to you, in fact.

Since you're using Swing you will have noticed the "listener" concept. Why don't you use that concept too? You need to make your information source have an "addWhatsitListener(WhatsitListener listener)" method, and you need to make your information receivers implement the WhatsitListener interface, which will just have a single method.

When the information source has something to say, it simply goes through all of the WhatsitListeners which have registered themselves with it and calls that single method on each of them. Look closely at your Swing listeners and you'll see how it's done.
Fred Hamilton
Ranch Hand

Joined: May 13, 2009
Posts: 679
Valid points, I see what you are saying but I kind of think I haven't really done a good job of explaining what it is I'm doing. The point of using I/O streams is not so much that I can get my two components ( a GUI and an engine) working well together, but that I can make my components interchangeable with components that other people have designed, often in other languages. For example, I may want to interface my GUI with a windows .exe engine. I think this is why I/O streams are used for the interface.

Anyways, what I am talking about is chess programs, there are a few GUI's out there , and lots of engines, and there are two standard protocols for interfacing the two, and both use I/O streams. I'm just getting started in this field, and I'm using Java not because it is the best language for the purpose, but because I want to learn Java.

I hope this clarifies the situation somewhat.

best regards,
Fred.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Event Listener for JTextArea?