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.
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.
Joined: May 13, 2009
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.
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.
Joined: May 13, 2009
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.