Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

program won't wait for input  RSS feed

 
Karen Guffey
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to create a Coke vending machine, which started out as fun, but I've gotten stumped in an odd place. I can't get a method to wait for input. I'm pretty sure it has to do with those daggone brackets again, because I remember moving one or two & then getting what I wanted, but then it messed up other parts of the program. I decided to run one method at a time, but now no matter what I do with those brackets, I can't get it to wait for input.


Lines 10 & 29 expect reader input. But the program doesn't wait for it, as it usually does (as when it waits to read a float for "credit"). If the credit is more than .65, the program prints out the next 3 lines & ends the program. If it's more than .65, it keeps asking, as it is supposed to, for more money, & when it has enough, it prints out the next 3 lines AND the string on line 34.

I'm tearing my hair out. Please help!
 
Tushar Goel
Ranch Hand
Posts: 934
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In line 4 you have used 'input.nextFloat()', after enter the input when you hit enter it will consider that as an input for line 10,hence it is not waiting for user to input it.
You can check Campbell Ritchie previous posts on scanner. He explained this things in very good way.
 
Knute Snortum
Sheriff
Posts: 4073
112
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's happening is that when you use nextFloat() to get a value and you press <Enter>, it leaves a CR in the buffer. nextLine() sees this and thinks you've entered an empty line, so it proceeds.

The best way to stop this is to use next() to get Strings. Use nextLine() only for "Hit <Enter> to continue" situations.
 
Karen Guffey
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
THANK YOU!!! You guys are sanity savers!
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Knute Snortum wrote:What's happening is that when you use nextFloat() to get a value and you press <Enter>, it leaves a CR in the buffer. nextLine() sees this and thinks you've entered an empty line, so it proceeds.

The best way to stop this is to use next() to get Strings. Use nextLine() only for "Hit <Enter> to continue" situations.


Then again if you do that, don't use Scanner since you need to check for int with a try/catch clause anyway. Using Scanner in this case will just make your application slower without any gains. .

I personally don't use scanner and probably never will. On top of providing the strange behavior the user experienced , scanner is really slow:

Parsing 20,000,000 int from file like it is typically done in real life batch jobs:.
With scanner:
20000000 int scanned in: 123 seconds

No scanner (more than 10 times faster! and the code isn't that much more complicated nor rocket science!)
20000000 int parsed in: 10 seconds












 
Campbell Ritchie
Marshal
Posts: 55698
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A buffered reader might be faster for a text file, but the few μs difference is overwhelmed by the two seconds it takes to enter data by hand. Scanner also has the advantage that it does the parsing for you. It also consumes the Exceptions. It also allows a loop which will prompt for a repeat if your input is in the wrong format.Please don't write such long lines. Don' use doubles or float for msoney. Don't use floats for anything (unless there is an API which requires floats). Read about big decimals in he two links in this post.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!