Posts by JamesCherrill

paintComponent still only paints the first image
g2D.drawImage(bi, x, y, this);

The draws to big and big2 don't achieve anythig as far as I can see

First split the String into words (see the split(...) method in String class), process each word using charAt etc, the put all the words back together into a sentence.

We've all don ethat at some time or another! Mark as solved?

In your asctionPerformed you seem to be moving the bullets r/l as well as the spaceship? Is this what you intended?

I don't see why this is a problem! You fire the bullet. It has an initial position and velocity that depends on the position and velocity of the ship at that time. The bullet's position and veocity should have no connection with the ship once they are initialised - after that it just goes its own way.

Last time I wrote a chess program (yes, really) that's what I did and it worked very well - clear code and efficient running. I used ImageIcons in the JLables to show the pieces. I can share some bits of code if anyone needs convincing!
ps: Sorry - small correction - I just checked and it was actually a 8x8 array of JButtons - a bit easier to handle mouse clicks, that's all

GridLayout - 64 JLabels is no problem whatsoever.

To execute custom code of your own on JFrame closing use a WindowListener.
http://download.oracle.com/javase/tutorial/uiswing/events/windowlistener.html

An Exception is basically a data structure used to transmit information about an error from the source of the error back up to a calling program. An Exception handler is a piece of code that catches and deals with an Exception (eg prints an error message). The Exception class may have methods that the handler can use, eg to print the stack trace, but the specific handler has to decide whether and when to use those methods.
The code you just posted seems way over the top. All you need is

public class CheckInException extends Exception {
    public CheckInException (String message) {
        super(message);
    }
}

In your checkIn method you can then just say:

if (some error has been detected) 
  throw new CheckInException("Some suitable error description");

Then any code that calls your method can simply catch(CheckInException e) {...
to handle the Exception as it choses.

ps
The code that throws the exception knows that a problem has happened, but doesn't know what is the right thing to do about it - eg it doesn't know whether it's been called from a console app (so the message should go to System.out), or a Swing GUI (in which case it needs an error dialog box), or a web server (send the message as an HTML page). This is also true of the Exception class itself.
The calling program (try/catch exception handler) doesn't know the details of how the problem was detected, but it does know …

You may be confusing "creating an exception handler class" with "creating an exception class". I haven't seen examples of people creating a class just to handle an exception (except for a couple of very complex distributed apps), but it's normal to create a new exception class when you perform error checking and want to throw an exception that shows exactly what kind of error it was (eg CheckInException for errors in your checkIn method).

Your line nos seem 1 out from the error messages, but
studno1 = new JLabel(text[9]); is the line in question
text = new String [9]; is the size of "text"
so the valid array indexes for text are 0..8

An exception handler is basically just a catch clause that does whatever you need to deal with the exception when it is thrown. Just displaying an error message is a good start. After that you may want to go back and try again with new input, or whatever.

Method 1 calls method 2 from inside a try block
Method 2 throws an exception
Method 1 catches exception in a catch clause
Catch block does something appropriate - this is the exception handler.

The idea is that if your method may have errors it can't deal with it should throw some kind of Exception. There's nothing to stop you throwing one of the Exceptions that are defined in the Java API, but it's far more helpful to define a new Exception type of your own that makes it perfectly clear what's happening. That is what the code for "ExceptionHandler" does, although its name is very bad - this isn't a handler, it's just a custom Exception type. It would be better to call it something like CheckInException.
Then in your main you can use try/catch to deal with these CheckInExceptions like you said in your EDIT:

Line 30 you create a new array variable rather than using the existing "values". The new variable goes out of scope at the end of that method, leaving the original still null

Are Exam and its implementation the same thing??

No, but in this case the method is defined as returning an Exam. Because Exam is an interface you cannot instantiate one directly. If ExamImpl implements Exam then this is a class that you can instantiate, and any instance of it will also be an Exam, so it is valid to return an instance of ExamImpl where the return type is defined as Exam.

I don't know why the add/remove thing isn't working. I've used setVisible myself in the past to do things like this and I admit that because it's simple and it works I just stick to that.

A couple of things to try...
Call revalidate() rather than just validate() after changing contents.
Rather than remove/add, maybe try setVisible(...) to show/hide the two panels?

I missed that! Good point quuba. Never mix AWT and Swing components.

Do you mean it never displays the controls, or is the problem when you click the buttons that change between the two panels?
Have you tried to pack() the JFrame after adding or removing the panels?

Yes, of course you can catch it, but you don't have to. Even worse, unless you study the complete source code of the public method you are calling, you have no way to know that this exception may be thrown and are therefore very unlikely to write a try/catch for it.

I can see why width or height <0 would be an error, but what's wrong with negative x or y? Haven't you even moved a window so its top left corner is just off the screen?

You use IllegalArgumentException as your exception. This is a kind of RuntimeException which means it is unchecked - ie you are not required to catch or declare it as thrown; the program can just exit without any diagnostics.
This kind of exception was never intended for ordinary user data input errors, which should always be handled explicitly in your code. You should use an ordinary checked exception (see firstPerson's post), declare your methods as throwing that exception, and thus ensure that the calling code has to deal with the user error

There's no code there to add any controls to a JPanel.

It's rarely a good idea to just guess method names - have a look at the API doc for the Date class - you'll soon find the method you need.

You have most of it there. Parse the input to a Date, get "now" as a Date, then get the time in millisecs from those. Subtract the two millisecond values and divide by 60,000 to get minutes.

You refer to the list using the class name, so that will only work if the variable is static. If it's not static you need to refer to it through an instance of the class, as in

myPackage.firstClass otherClassInstance = ... get a reference to an instance of the other class
int index = otherClassInstance .myList.getSelectedIndex();

Once this is fixed you can see if there are any other problems ;-)

is myList static?

Yes (except that ints in Java are 4 bytes, 0x00000002)

No. You may be failing to distinguish between a class and an instance of that class.
You need Panel.class ( not java) at the client end so that the JRE understands what a "Panel" is. You can then use ObjectStreams to send/receive individual instances of Panel.

DataOutputStream outputs data in its raw binary form - eg always 4 bytes for an int
PrintStream outputs data in a human-readable character format - so an int could be anything such as "0" or "-1234567"

The API doc BufferedInputStream has, as its very first sentence:

A BufferedInputStream adds functionality to another input stream-namely, the ability to buffer the input and to support the mark and reset methods

and the source code for BufferedInputStream includes this:

public synchronized void mark(int readlimit) {
	marklimit = readlimit;
	markpos = pos;
    }
...
    public synchronized void reset() throws IOException {
        getBufIfOpen(); // Cause exception if closed
	if (markpos < 0)
	    throw new IOException("Resetting to invalid mark");
	pos = markpos;
    }

I guess that's pretty clear then?

You can leave the text field as it is and fix the commas after you read the text into your program, ie
String textWithoutCommas = loanText.getText().replace(",", "");

Could it be that BufferedInputStream implements it?

How do you know it's not returning? Because this is part of a window closing event how would you expect a return to manifest itself?
Anyway, put a print statement just before the return to see if its being executed.

I don't know the answer, but I know where you can find it...
the entire source code of the API classes is freely downloadable from
http://download.java.net/jdk6/source/
so you can look at the code and see exactly how it is written.

1. Create a new class that contains a label and a textfield and write the necessary constructor(s) and other methods.
2. If you just want it for positioning etc, put them both in a JPanel

Set the timer to fire (eg) once a second. In the ActionListener update the JLabel and keep a running count of the total seconds. When the total reaches your time limit, stop the timer and do whatever else is needed.
The Timer class uses Swing's event dispatch thread and its related queue (same as is used for popping up tooltips after x millisecs etc), so it's a very efficient and solid implementation. You won't need any other threads unless you get into long-running task steps (eg massive computations, or slow network accesses)

That whole block of code simply tells Java to exit the app when the window is closed, so just remove it or each window that should not call System.exit when it is closed.

Your pseudo-code looks OK.
Now, back to the test driver.
You have all your code in main, which makes this difficult - so the first thing is to move the number generator into a new method that returns an array of 50 different random numbers, eg

public int[] generateNumbers() {
  // generate and return the numbers
}

Now you have your code in its own method you can use main(...) to test that method, eg

public static void main(String[] args) {
   int[] numbers = generateNumbers();
   // now print the numbers in the array to see if they are OK
}

This is a particularly simple example, but that's how test drivers for small programs or classes typically work. You put the code into methods, then write a small main(...) method that calls your methods and displays or checks the results.

There's also a truly hideous workaround...
http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ609

I don't have the references in front of me right now, but there is a solution that involves passing a "dummy" arg to the constructor whose type has to be <T>, then you can use the class of that param at runtime to instantiate your own vars with the same class. (I guess that's what's happening when you pass an empty array to ArrayList's toArray mathod.)

You should use the swing timer for ordinary tasks that relate to swing GUIs. util.timer is for more general/complex timing tasks.

passnum = 26;}

int table[][] = new int [26][26];

table[passnum][passnum[i++]]++

Now can you see it? (the max valid index for an array[26] is 25)

Wrong. JFrame has paintComponent. Just add your buttons to the JFrame,and override paintComponent.

I think the contantpane stuff is irrelevant - before Java 1.5 you had to add things to the contentpane, but since then you just add them to the JFrame.

You add the Ok1 panel to the frame, then you add the button, so these will be one after the other, not one on top of the other. I don't see why you were advised to put a panel in the frame anyway.

If you go right back to the very first version you posted and just change paint to paintComponent that should work (or at least get very close to working)

Hi Sunshineserene - I'm not ignoring you,, but while hanvyj is working with you I think it's best for me to keep quiet - two sets of advice simultaneously is bound to be confusing.

Sunshineserene: you are making this very difficult for anyone to help you because your problem description is so vague.
Exactly which array in exactly which class is being "called" from exactly where? Please specify the exact line numbers where the variables and code in question can be found.

You have overidden paint(Graphics g) but this is not a recommended practice. paint(Graphics g) also has responsibility for painting child objects etc, and this can all get lost when you override it.
The recommended practice is to override paintComponent(Graphics g) instead. You override it in exactly the same way, but now you're not interfering with the painting of child objects, frames etc.

http://java.sun.com/products/jfc/tsc/articles/painting/#callbacks

Here, stripped of all the error handling etc, is the essential sequence of steps:

JFileChoser jfc = new JFileChoser(...
jfc.showSaveDialog(...
File f = jfc.getSelectedFile();
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(f));
oos.writeObject(myObject);
oos.close();

You can get all the error and exception handling from the examples you have already found.

JFileChooser gives you a file.
Serialization writes to a file.
You really don't need anything else. Just start with the file chooser and use its file in the serialization. One just goes right after the other. Try it.

:)
Mark as solved?