Prev: Newbie again. "Java Keyboard input" is a failure as a google search. What isn't?
Next: Your Helping Heart
From: Arne Vajhøj on 19 Jul 2010 19:20
On 19-07-2010 03:18, Stefan Ram wrote:
> Simon Brooke<stillyet+nntp(a)googlemail.com> writes:
>> It seems perverse to go to the overhead of building a complete WIMP user
>> interface to do
>> for ( int c = System.in.read(); c> -1; c = System.in.read()) {
>
> The OP said �reading input from the keyboard�.
>
> �System.in� might be associated with any file or device
> whatsoever on program start-up, beyond the control of the
> Java-program running. So, the program can not know whether
> �System.in� is connected with the keyboard at all.
>
> This is not just a remote possibility. Instead �redirecting�
> System.in is used often.
>
> A JTextField /is/ certainly associated with the keyboard,
> which is what was asked for: �reading input from the keyboard�.

It is absolutely not certain that JTextField is associated with
the keyboard.

Sure you can not redirect it. But you can have a context with
no Swing support. Very easily.

Arne
From: Arne Vajhøj on 19 Jul 2010 19:21
On 19-07-2010 02:58, Mike Barnard wrote:
> On Sun, 18 Jul 2010 22:48:28 -0400, Arne Vajh�j<arne(a)vajhoej.dk>
> wrote:
>
>> On 18-07-2010 11:52, Simon Brooke wrote:
>>> On Sun, 18 Jul 2010 10:59:06 +0000, Stefan Ram wrote:
>>>
>>>> Mike Barnard<m.barnard.trousers(a)thunderin.co.uk> writes:
>>>>> So, can the Fount Of All Knowledge point me to a good tutorial on the
>>>>> most efficient methods to get input from a user please? I don't expect
>>>>> hand holding, honestly, just pointers to really useful tutorials.
>>>>
>>>> To get text from the keyboard, the most obvious means to me would be a
>>>> javax.swing.JTextField.
>>>
>>> Errrrr.... WHY?!?!?!?
>>>
>>> It seems perverse to go to the overhead of building a complete WIMP user
>>> interface to do
>>>
>>> for ( int c = System.in.read(); c> -1; c = System.in.read()) {
>>> char ch = (char) c;
>>> /* now do something with ch */
>>> }
>>>
>>> In practice something like the following would be more useful:
>>>
>>> string readLineFromStdin() {
>>> StringBuffer buffy = new StringBuffer();
>>> bool reading = true;
>>>
>>> while ( reading) {
>>> int c = System.in.read();
>>>
>>> switch (c) {
>>> case 10:
>>> case 13:
>>> case -1:
>>> reading = false;
>>> break;
>>> default:
>>> buffy.append( (char)c);
>>> break;
>>> }
>>> }
>>> return buffy.toString();
>>> }
>>>
>>> although in anything but the simplest utility programs you'd probably do
>>> something a touch more sophisticated than that.
>>
>> No - you would do it a lot simpler than that in any program.
>>
>> BufferedReader or Scanner will save a lot of code.
>
> As I'm finding out, thanks. However, would the above teach me anything
> about 'how it works' even if it is overly wordy?

No.

Not unless you count "learning good 1980 C code programming
using Java as language".

Arne
From: Arne Vajhøj on 19 Jul 2010 19:22
On 19-07-2010 07:33, Simon Brooke wrote:
> On Mon, 19 Jul 2010 07:58:28 +0100, Mike Barnard wrote:
>> On Sun, 18 Jul 2010 22:48:28 -0400, Arne Vajhøj<arne(a)vajhoej.dk> wrote:
>>> On 18-07-2010 11:52, Simon Brooke wrote:
>>>> On Sun, 18 Jul 2010 10:59:06 +0000, Stefan Ram wrote:
>>>>
>>>>> Mike Barnard<m.barnard.trousers(a)thunderin.co.uk> writes:
>>>>>> So, can the Fount Of All Knowledge point me to a good tutorial on
>>>>>> the most efficient methods to get input from a user please? I don't
>>>>>> expect hand holding, honestly, just pointers to really useful
>>>>>> tutorials.
>>>>>
>>>>> To get text from the keyboard, the most obvious means to me would
>>>>> be a javax.swing.JTextField.
>>>>
>>>> Errrrr.... WHY?!?!?!?
>>>>
>>>> It seems perverse to go to the overhead of building a complete WIMP
>>>> user interface to do
>>>>
>>>> for ( int c = System.in.read(); c> -1; c = System.in.read()) {
>>>> char ch = (char) c;
>>>> /* now do something with ch */
>>>> }
>>>>
>>>> In practice something like the following would be more useful:
>>>>
>>>> string readLineFromStdin() {
>>>> StringBuffer buffy = new StringBuffer(); bool reading = true;
>>>>
>>>> while ( reading) {
>>>> int c = System.in.read();
>>>>
>>>> switch (c) {
>>>> case 10:
>>>> case 13:
>>>> case -1:
>>>> reading = false;
>>>> break;
>>>> default:
>>>> buffy.append( (char)c);
>>>> break;
>>>> }
>>>> }
>>>> return buffy.toString();
>>>> }
>>>>
>>>> although in anything but the simplest utility programs you'd probably
>>>> do something a touch more sophisticated than that.
>>>
>>> No - you would do it a lot simpler than that in any program.
>>>
>>> BufferedReader or Scanner will save a lot of code.
>>
>> As I'm finding out, thanks. However, would the above teach me anything
>> about 'how it works' even if it is overly wordy?
>
> If I hadn't thought it would, I wouldn't have posted it...
>
> Underneath anything that reads from an input stream in Java is that basic
> method read() returning an int, -1 in the case of end of stream,
> otherwise 0-255 indicating the byte read. This may seem odd given that
> Java characters are sixteen bit, but remember that this language was
> designed as a language primarily for small embedded systems. At it's
> lowest levels it's quite simple and even primitive.

The fact that chars are 16 bit does not have much relevance for
a method returning bytes (which are 8 bit).

Arne

From: Arne Vajhøj on 19 Jul 2010 19:24
On 19-07-2010 02:53, Stefan Ram wrote:
> Tom Anderson<twic(a)urchin.earth.li> writes:
>> But if what you want to write right now is an interactive command-line
>> program, then System.in is the only thing that helps you
>
> When one wants to read characters (like German Umlauts) with
> the console encoding and this console encoding differs from
> the system encoding (as sometimes under Windows), sometimes,
> its better to wrap java.io.FileDescriptor.in with the
> required encoding than to use System.in. -- And then,
> suddenly, a Swing-program to do the same, might not be much
> more difficult anymore.

As a rule of thumb then I would say that the need to go beyond
plan US ASCII makes GUI (Swing or SWT) attractive compared
to console.

But I still think that it makes sense to start with console.

Arne
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Newbie again. "Java Keyboard input" is a failure as a google search. What isn't?
Next: Your Helping Heart