> okay...hehe lets try this again here is my program in FULL (as it is a
> very small and simple program i will give all the code in full)
[code snipped]
> hopefully posting my entire program was not an overkill but based on
> SSCCE...it needed to be compileable...and there was no way of easily
> making my "problem" compilable w/out possibly changing things that
> would cause another problem or temporarily 'fix' the problem i have
> now...so ya.....
If you "temporarily fix" the problem you had, why don't you look at what
change you did, and try to think about why it fixed the problem. Maybe
that'll lead you to a solution.
Anyway, here's a temporary fix for you: Change the line that reads
<oldCode>
answer = keyboard.nextLine();
</oldCode>
to
<newCode>
answer = keyboard.nextLine();
answer = keyboard.nextLine();
</newCode>
To understand why this works, think about what the order of calls on the
keyboard object are. First its nextInt(), then nextDouble(), then
nextLine(), then nextDouble(), then nextLine(), and so on.
When the program asks me how many pieces of wood, I'll type in, for example
"1" followed by the enter key.
nextInt() eats up the 1, but the newline is still in the buffer.
Then when it asks for the length of the wood, I type in, for example "10"
followed by the enter key.
nextDouble() skips the whitespace of the newline that's in the buffer, then
sees the 10, and eats that up. But there's the second newline still in the
buffer.
then when you call nextLine(), it eats up the newline in the buffer and
returns immediately.
You need another call to nextLine() to wait so that the console will pause
and wait for the user, for example, to type in "y" followed by enter.
Of course, just putting two nextLine() calls one after the other is a
horrible way to fix this. Now that you have an understanding of what the
problem is, maybe you can figure out a "proper" way to fix it.
- Oliver
> okay...hehe lets try this again here is my program in FULL (as it is a
> very small and simple program i will give all the code in full)
****************************************************************************
*************************
> implementation file
****************************************************************************
*************************
> import java.util.*;
> import java.text.*;
[quoted text clipped - 83 lines]
> }
> }
****************************************************************************
*************************
> driver file
****************************************************************************
*************************
> import java.util.*;
>
[quoted text clipped - 15 lines]
> }
> }
****************************************************************************
**********************
> hopefully posting my entire program was not an overkill but based on
> SSCCE...it needed to be compileable...and there was no way of easily
[quoted text clipped - 3 lines]
>
> round 3 DING DING
The problem with "round 2" was that 'keyboard' wasn't defined. You dealt
with that in "round 3" by showing us how 'keyboard' was defined but it is
based on a class called Scanner which you haven't shown us. Therefore, we
don't know what the Scanner class is - it's not part of the standard Java
API - so we still can't help much. I assume that someone, a teacher
probably, gave you the Scanner class to use to simplify the coding of your
read logic.
Rather than asking you to provide the source code for Scanner, which may use
non-standard classes too for all I know, I'm going to suggest a fairly
straightforward way to do screen I/O that I use in my programs. If you use
this technique, you should be "good to go". In addition, you will be using
standard classes that anyone with Java experience will recognize. That's a
lot easier for *ME* than trying to debug the mysterious Scanner class
without its source code.
So here's how I do console I/O. I'm not saying this is the best or only way
to do what you want but it should get the job done.
BufferedReader rdr = new BufferedReader(new InputStreamReader(System.in));
System.out.println("Enter your first name:");
String firstName = rdr.readLine();
Here's a brief explanation. 'rdr' is a BufferedReader; it is wrapped around
an InputStreamReader which is reading 'System.in' which is the keyboard
input. (For a proper discussion of Streams and Readers, take a look at the
Java Tutorial chapter; here is a link to the appropriate chapter:
http://java.sun.com/docs/books/tutorial/essential/io/index.html.) You only
need to create 'rdr' once, not before each line is read from the keyboard.
The System.out.println("") simply displays a prompt that tells you what
input you are supposed to give.
The third line reads a line from the console and stores it, as a String, in
the variable 'firstName'. Anything read via a BufferedReader is always a
String, even if it is only digits. (If you are inputting a number that needs
to be treated as a number, there are standard classes to convert it to the
appropriate number format.)
All you have to remember is that the user needs to type his response to the
prompt and press ENTER before the program can see the response.
I hope this helps you and doesn't get you into trouble with your teacher for
not using the Scanner class.
Rhino
Oliver Wong - 10 Nov 2005 23:25 GMT
> The problem with "round 2" was that 'keyboard' wasn't defined. You dealt
> with that in "round 3" by showing us how 'keyboard' was defined but it is
[quoted text clipped - 3 lines]
> probably, gave you the Scanner class to use to simplify the coding of your
> read logic.
Actually, java.util.Scanner was added in Java 1.5.
[snip]
> So here's how I do console I/O. I'm not saying this is the best or only
> way
[quoted text clipped - 3 lines]
> System.out.println("Enter your first name:");
> String firstName = rdr.readLine();
I agree that Rhino's implementation here is probably more robust than
using the Scanner class with intermittent nextLine() calls. Alternatively,
use nextLine() consistently in the Scanner class.
- Oliver
Bjorn Abelli - 11 Nov 2005 00:16 GMT
"Oliver Wong" wrote...
> "Rhino" wrote...
>
[quoted text clipped - 6 lines]
> using the Scanner class with intermittent nextLine() calls. Alternatively,
> use nextLine() consistently in the Scanner class.
As Oliver wrote in another post in this thread, you need to know what
Scanner actually does, and what to expect from it. It's *not* a simplified
"Reader-class" but can be used as such if used properly.
He also suggested a workaround in that post.
Another workaround could be to not only be consequent by "eating" the
newlines, but to start with a simpler use of the Scanner instance, by *only*
using nextLine, e.g. changing
keyboard.nextInt()
into
Integer.parseInt ( keyboard.nextLine() )
and
keyboard.nextDouble()
into
Double.parseDouble ( keyboard.nextLine() )
// Bjorn A