Posts by JamesCherrill

Excellent! Mark this thread "solved" now, you can start another if you hit a new peoblem.

You can open an output file in append mode.
If you append one byte to the file each time you create an instance, then the length of the file will be the same as the number of instances created.
(You'll have to synchronize the relevant code to avoid thread-related problems)

You know that Java 1.4.x was replaced in 2004 by Java 1.5, which contains major enhancements to the language. We are now on Java 1.7
Your bug fixes and security patches are about 8 years out of date, it really is time to update.

You need to cast the result of the getClientProperty to the appropriate class, eg
(Boolean) getCli....
then, if you are on a version before 1.5, you need to get the boolean value from the Boolean object.

OK - run out of memory, then trying to execute a bind that has already been executed.
My best guess is that either you are in a simple infinite loop, or you are making a recursive call without a proper termination condition. I assume that would not be deliberate. Trace the execution with a few well-placed print statements.

Seems very unlikely that that code fragment, on its own, would run out of heap (unless you're using JavaME?). Maybe it's something in the rest of your code - can you post it all - if it's big a small runnable demo of the part that fails would be even better!

You don't need to test. You have this code:

System.out.println("Connecting to " + serverName
+ " on port " + serverPort);
client = new Socket(serverName, serverPort);
System.out.println("Just connected to "
+ client.getRemoteSocketAddress());
outToServer = client.getOutputStream();
out = new DataOutputStream(outToServer);

inFromServer = client.getInputStream();
in = new DataInputStream(inFromServet

so immeditately after in = new DataInputStream(... you can start thread 2 to wait for input from that data input stream

Like I said - start the read thread as soon as you have a socket connection, then just leave it running in its loop until you want to exit the program. That way it will respond to any input that comes in from the socket, whenever it may come in.

Just put the read into a loop within the run method - like this:

Runnable run2 = new Runnable() {//for reading from socket
boolean stop = false;
public void run() {
while (! stop) {
try {
displayTextArea.append(MainFrame.in.readLine() + "\n");
System.out.println("****");
} catch (IOException ex) {
Logger.getLogger(ChatPanel.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
};

OK.
You can start your run2 thread as soon as you have a socket connection. If you put all that code into a loop it will wait on the readLine until there is input, then process it, then go round the loop to wait again for the next line (etc).
Now yopu need to have the server send any inbound messages to all the clients.

What code do you have that uses the DataInputStream inFromServer?

You just posted the code that creates it, but where do you use it? Probably something that looks like inFromServer.read...

Sounds like you need the server to send each message to all the clients as soon as it's received?
What code do you have that uses the DataInputStream inFromServer?

I don't see any Socket code there - have you started it yet? If not, just do a really simple one that just send/recieves a single line and prints it out and exits. You can incorporate that code into the real multi-threaded system when it's working.

There's more than one way. Post you latest reader code so we can use that as the starting point.

Your reading thread sits in a loop waiting for input to arrive at its socket. When input arrives you call the Listener's method to display that input, then loops round to wait for the next input.

If both panels are running on the same machine,, then why not just have Chatpanel 1 call an update method in Chatpanel2?
If they are on different machines, then the standard solution is to implement a Listener interface for the receiver socket code. The code for Chatpanel2 should register itself as a Listener to the socket-handling code. When input arrives at the socket the code should call any/all listeners and pass the input to them so they can update themselves. This is the standard Listener pattern, as used throughout Swing.

@sheppy:
Your post is ringing alarm bells in my head! Can I ask why you are storing a Boolean in client properties? Row/col numbers made sense as the obvious way to identify which button was pressed. But the Boolean implies you are storing state information in the button itself, which sounds like a violation of the good design principle of separating GUI from application logic.

I'm using a version of java that doesn't have method overloading for putClentProperty...

just for the record (many people read these posts) it's not putClientProperty that has changed. Before Java 1.5 you had to convert between int and Integer explicitly (ditto boolean and Boolean etc). From 1.5 Java introduced "auto boxing/unboxing" that identifies many situations (like this one) and automatically converts between int and Integer (etc) when required. This is just one of many significant enhancements to the language in 1.5

All the public members of System are static, so there is no reason ever to instantiate one.

I don't know "ready to program" - maybe that IDE is long dead? However Java is very much alive, and NetBeans or Eclipse IDE's are in daily use by thousands of commercial developers.
You'll find other info on current software here:
http://www.daniweb.com/software-development/java/threads/99132

Oracle acquired the whole deal. Latest update was a few weeks ago. Current version is 1.7.something. Google it.

;-)
The secret of a fast reply is to keep it short!
This also ensures one doesn't give too much of the complete answer - just enough to get the OP thinking along the right lines.
@sagy - if your problem is answered correctly, please mark this thread "solved".

mybox.volume attempts to find a variable called volume in the Box class. You have no such variable (but you do have a method!).

That looks the wrong way round to me. Use the private constructors from inside the class when you know the parameters are valid. Force other people to use the public constructors that perform validation/normalization etc on the parameters before they call the private versions.

In this case they probably could use private methods, but the intention of the code is much clearer if they are constructors. It may also be the case that other ordinary methods in the class will call those constructors to create new Files, knowing that the parameters are valid. In general there are other differences between constructors and ordinary methods (eg initializing final variables) that may be relevant.

The code for File comments both those methods as follows:
* Internal constructor for already-normalized pathname strings.
In the File class the public constructors do some validation/pre-processing of their parameters, then call one of the private constructors to do the real work. They are private so nobody can call them directly and bypass the validation/pre-processing.

There are two fundamentally different approaches to this:
1. You run the program, then display the yes/no buttons. When the user clicks the "yes" button your event handler runs the program again. When he clicks "no" you exit. This approach doe NOT have an explicit loop
2. You start a loop. In it you run the program then you display a MODAL yes/no dialog which waits for the user to click a button. When a button is clicked you continue your loop or exit depending on which button. This approach does not have an event handler in your code (there is one, but it is handled within the modal dialog itself).
If your requirement is to use a loop, then approach 2 seems appropriate. Look at the showConfirmDialog(...) method in the JOptionPane class

One reason is to prevent anyone else from instantiating members that class by just using "new", eg if it needs to be instantiated by some special "factory" method. If you want to quote a couple of example classes that have private constructors we can give more specific answers for those.

You need Java 1.5 or later for the compiler to handle automatic conversion between int and Integer to make that code work. More seriously you are using a version that is many years out of date, with none of the latest security updates. For reasons of security you should update to a current version of Java immediately.

use putClientProperty to associate the row and column numbers with each button when you create them. In your ActionListener just use getSource().getClientProperty to get the row/col numbers for the button that was clicked. The documentation for these methods is, as always, in the Java API JavaDoc, and can also be found with Google. And no, I'm not going to write the code for you, but if you have a try and post what you have done when you get stuck I'll help you.

http://docs.oracle.com/javase/1.3/docs/tooldocs/win32/javac.html

If you do a System.exit your program will terminate immediately and any unflushed buffers will be discarded, and any system resources you are holding may not be released. You should use try/catch/finally to ensure files and closed and resources released, and ideally allow your program to terminate normally by finishing all your threads.

Yes, they are constants in the Color class. They look like this: public final static Color gray = new Color(128, 128, 128); You can use reflection to loop through all the variables in the class and select those which are public static final Colors - this code does that and returns a map of all the color names and the corresponding Color instances. Feel free to use it, as long as you leave the Author comment in place.

// get a map of all the Color constants defined in the Color class
   // Author: James Cherrill
   public static java.util.Map<String, java.awt.Color> getAllColors() {
      java.util.TreeMap<String, java.awt.Color> colors = 
         new java.util.TreeMap<String, java.awt.Color>();
      java.lang.reflect.Field[] fields = java.awt.Color.class.getDeclaredFields();
      for (java.lang.reflect.Field f : fields) {
         try {
            if (! java.lang.reflect.Modifier.isPublic(f.getModifiers())) break;
            if (! java.lang.reflect.Modifier.isStatic(f.getModifiers())) break;
            if (! java.lang.reflect.Modifier.isFinal(f.getModifiers())) break;
            Object o = f.get(null);
            if (o instanceof java.awt.Color) { 
               String name = f.getName();
               name = name.substring(0, 1).toUpperCase() +  
                      name.substring(1).toLowerCase(); // convert to title case
               name = name.replace("_",""); // de-duplicate Light_gray and Lightgray
               colors.put(name, (java.awt.Color) o);
            }
         } catch (Exception e) {
            e.printStackTrace();
         }
      }
      return colors;
   }

You can't do drawing in Swing like that, it's not how it works.
Create and use a subclass of JPanel and override its paintComponent method. When Swing needs to display your panel it will call your paintComponent, passing the correct Graphics object (actually an instance of Graphics2D) for you to draw your line on.

OK, thanks.

~s.o.s~ is there any particular reason for not using

while (!Thread.currentThread().isInterrupted()) {
  // do something

why are you using this if (counter % 3 = 2){ } i dont get the '% 3' and to be honest this must be the first time ive seen such an if statement

Me too, but not because of the %, but because it's not Java. It won't compile with a Java compiler. You can't assign the value 2 to the integer constant 3.
All together now children, repeat after me:
= is assignment
== is the test for equality

:twisted: J

OK, you are doing two things that will cause problems - you are running at an arbitrary speed, depending on available CPU time, and you are trying to bypass Swing's normal mechanisms by drawing to screen.getGraphics(); from another thread.

There is an absolutely standard "correct" way to do this, which separates the real-time simulation from the Swing-managed screen updates and other Swing UI activity. It goes like this:
Use a Timer to call a "physics update" routine at a fixed speed - 60/second is plenty. In that routine update everything's position and velocity variables. but do no painting. Just call repaint() on the appropriate panel to let Swing know the screen needs to be updated.
In the panel's overridden paintComponent method, draw everything according to its current position.
Handle keyboard and mouse input vie the normal Swing listener interfaces, in them just set variables that the physics update routine will use when it runs.

That way you ensure that the simulation proceeds at a steady fixed speed, regardless of hardware (assuming it's "enough" hardware, of course). Swing will schedule screen updates as fast as it can - if repaint() gets called more than once between screen updates the duplicate repaints will get merged int one. If you have fast enough hardware you will get a 60fps display, if you have slower hardware you will get a lower fps, but still a constant-speed sprite movement.

Means unless we are updating or modifying something there is no need to make such methods synchronous?

This will be true most of the time, but if you are accessing more than one value in such a method you may get inconsistent values for them when another thread modifies the data between the accesses. I agree with rubberman, the storeUser method should be synchronized on the target data store object.

you can't have two public classes in one file, you can have only one public class, which has the same name as your java file.

... except for inner classes (as is the case in this thread).

I don't know - I use Eclipse myself. Whatever the reason, your buttons look like buttons with no text. Maybe try setting some arbitrary text explicitly on those 2 buttons just to see if that was the problem?

Which of these rules am I violating on line 23 where I get the error message? I'm just trying to create an instance of class like I always do. What is the non-static variable that the compiler is complaining about?

It's the inner class Counter, which is not static. So new Counter(); is trying to reference the non-static class Counter. This tutorial may help clarify this (to be honest, rather obscure) problem.
http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

Also - you can't just stop a thread that's busy doing stuff. Here's a really good article on how to interrupt an running thread:
http://www.techrepublic.com/article/interrupting-java-threads/5144546

Looks like those 2 buttons don't have their text set explicitly. maybe?

The join statement won't be executed until "some heavy work" is finished anyway, so the timeout won't be useful. I think you need to start a second thread (or just a Timer) that waits for timeout milliseconds, and use that to terminate your work thread if necessary.

How is update called - do you use a javax.swing.Timer?

Yes, because Swing isn't thread-safe any code that updates anything related to the GUI should be run on the EDT, so you use invokeLater or invokeAndWait to run them if you are on another thread. (Except, as it happens, updating the text of a JLabel is one of the very few things that can be done safely from another thread.)

Here is a brilliantly clear explanation of the difference between validate and revalidate:
http://www.jguru.com/faq/view.jsp?EID=88716

@Traps: I don't know why you posted that in this thread, but SwingUtilities.invokeLater runs things on the Swing EDT, and is therefore absolutely NOT intended for "working with large collections of data" - that's a complete mis-use of that method.
SwingWorker, on the other hand, is intended for long-running tasks, and provides mechanisms for displaying intermediate results, and dispatching the final results back to an EDT method for display. You can, if you want, write your own code to run a task on your own thread and handle the synch with the EDT and transfer back to the EDT to display the results. But unless you have some very special requirement, you should use the standard methods provided for that purpose.

If I can make a suggestion...
There's a lot going on here for a beginner. Why not break it down into easy steps that you can work out one at a time:
1. Write, test and debug a version for numbers 1-19 only.
2. When that's working, enhance it to do numbers 1-99
3. When that's working, enhance it for the full range of numbers.

OK, fair enough. I was only pursuing it in case you had had some cunning idea that I could steal :)