Coding question - Printable Version

Coding question - Printable Version

+- Southperry.net (https://www.southperry.net)
+-- Forum: Social (https://www.southperry.net/forumdisplay.php?fid=14)
+--- Forum: Rubik's Cube (https://www.southperry.net/forumdisplay.php?fid=58)
+--- Thread: Coding question (/showthread.php?tid=36743)

Coding question - Lord Xela - 2011-01-23

So I'm in the process of doing my senior project (college senior, CS major) and I'm currently stuck on this one bug that I can't figure out. The project is a simple chatting client (think AIM, only less fancy) that I'm making for our ITS department to use as an alternative means of contact for students with questions, and I'm working in Java.

Now that the background is done, here's the actual bug. When I send a message from one client to the other, they both display the messages. That's normal. When it reaches the bottom of the JTextArea I'm using to display the messages, however, problems happen. The SENDING client has no issue - the window scrolls down automatically to display the most recent line. The RECEIVING client, however, does not scroll down until either the user does it manually or that client sends a message, at which point it jumps to the bottom as it should be doing. The code I'm using to update the JTextArea is

Code:
convo.setText(convo.getText() + makeTimeStamp() + "Me: " + s);

when sending, and

Code:
convo.setText(convo.getText() + makeTimeStamp() + "Client: " + s + "\n");

when receiving. The variable s in both cases is the string that's getting displayed, the names "Me" and "Client" are there as temporary for now, and the makeTimeStamp() method just creates a timestamp and returns it as a string. The newline is appended to the received message and not to the sent one because of the way the data streams work. Before sending, I trim all whitespace and then add one newline, so sending s has "\n" on the end. When I use readLine() on my input stream, however, it reads until it finds a newline and takes everything before it, so I have to add on the newline manually.

The point I'm making is that other than the slight formatting difference with how the newline is appended, the code for each of these setText() calls is identical, thus my issue with finding the bug. The only thing that I can think of that could be causing it is that the receiving setText() call is called from a second thread, which I have as a stream listener so that the program isn't locked up at all times and I can actually send messages and do other things as well. If the fact that a setText() from a second thread and not the main thread is causing it, does anyone have a solution to this? And if not, does anyone have any idea what might be causing my problem?

Coding question - Nikkey - 2011-01-23

First I thought of was that threading might be the error.

If you make the sender and receiver calls _exactly_ the same, e.g. by doing a call the main thread listens to, it would probably be easier to debug at least. I suppose this should solve it, but I've not seen you code, so well...

It could be that it is unsynchronized as well, as unsynced things usually do random things from my experience.

If not, try using setCaretPosition?

Coding question - Lord Xela - 2011-01-23

The setCaretPosition() thing might work. My only concern with that is that the JTextArea in question is set to be uneditable, so there's no (visible) caret. I assume it still tracks the location of where it would be, though. As for the synchronization comment, I don't know exactly what you mean by that but it isn't random - the behavior is entirely predictable. Odd, but predictable. And the first thing you mentioned - I assume by that you mean have the listener thread somehow tell the main thread to do the setText() call rather than doing it itself. The problem there is that I don't know how. Are there special methods within the Thread class for doing things like that?

Coding question - Spaz - 2011-01-23

Lord Xela Wrote:So I'm in the process of doing my senior project (college senior, CS major) and I'm currently stuck on this one bug that I can't figure out. The project is a simple chatting client (think AIM, only less fancy) that I'm making for our ITS department to use as an alternative means of contact for students with questions, and I'm working in Java.

Now that the background is done, here's the actual bug. When I send a message from one client to the other, they both display the messages. That's normal. When it reaches the bottom of the JTextArea I'm using to display the messages, however, problems happen. The SENDING client has no issue - the window scrolls down automatically to display the most recent line. The RECEIVING client, however, does not scroll down until either the user does it manually or that client sends a message, at which point it jumps to the bottom as it should be doing. The code I'm using to update the JTextArea is

Code:
convo.setText(convo.getText() + makeTimeStamp() + "Me: " + s);
when sending, and

Code:
convo.setText(convo.getText() + makeTimeStamp() + "Client: " + s + "\n");
when receiving. The variable s in both cases is the string that's getting displayed, the names "Me" and "Client" are there as temporary for now, and the makeTimeStamp() method just creates a timestamp and returns it as a string. The newline is appended to the received message and not to the sent one because of the way the data streams work. Before sending, I trim all whitespace and then add one newline, so sending s has "\n" on the end. When I use readLine() on my input stream, however, it reads until it finds a newline and takes everything before it, so I have to add on the newline manually.

The point I'm making is that other than the slight formatting difference with how the newline is appended, the code for each of these setText() calls is identical, thus my issue with finding the bug. The only thing that I can think of that could be causing it is that the receiving setText() call is called from a second thread, which I have as a stream listener so that the program isn't locked up at all times and I can actually send messages and do other things as well. If the fact that a setText() from a second thread and not the main thread is causing it, does anyone have a solution to this? And if not, does anyone have any idea what might be causing my problem?

Are you SURE the newline is getting put on the end with both? Have you tried using a debugger to check exactly what text is getting set?

Coding question - Lord Xela - 2011-01-23

a) Yes, I have checked that with a debugger. And even if I hadn't, the newlines display properly in the JTextArea. The line formatting is just fine - it just doesn't scroll.
b) Also, this line of code is 3 above the setText() that doesn't contain an explicit newline character:

Code:
s = s.trim() + "\n";

The two lines between that and the setText() call are the out.write() and out.flush() calls that send the message. Also, if you don't know trim(), it just deletes all whitespace characters before and after the string (in case there are any extra newlines that I don't want to have, lest my formatting get ruined).
c) The one that doesn't have the explicit newline character is actually the one that works fine. It's the other one that fails to scroll properly.

I've been a bit busy with other stuff, but I'm going to try that caret thing now. I'll post (or just edit this) with results.

Edit: Finally got to testing it. A quick line of code seems to have fixed my bug. I figure it isn't the best or most elegant way to do it, but hey, it works. If someone has another suggestion that would address the actual source of the bug, though, I'm still interested in hearing it.

P.S. The line that made it all happy again:

Code:
convo.setCaretPosition(convo.getText().length());