Not done any console apps in a long time.
If I do:
var c: char;
   read(c);

It will read individual files, but only after I pressed enter on my terminal. What is needed to read the char immediately?

This is rather platform specific, since you have to set your terminal into non-canonical mode. You should be able to use the functions in the keyboard unit to do this in a cross platform way.

Henry

It really needs get(c) but this function, together with put(c), which were defined in Jensen & Wirth and all standard Pascals, has long been missing from Turbo Pascal, and all its deriviatives such as Freepascal.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111118/40fcd054/attachment.html>

FPC is starting to get ISO Pascal support, so they might get implemented sooner or later. See also
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Basic_ISO_Standard_Pascal_support

Regards,
Sven

Chris Kirkpatrick wrote

It really needs get(c) but this function, together with put(c), which were defined in Jensen & Wirth and all standard Pascals, has long been missing from Turbo Pascal, and all its deriviatives such as Freepascal.

How does get(c) differ from read(c)? The problem here is with the terminal buffering the characters until return is pressed, hence the need for re-configuring the terminal so that each key press is sent immediately.

Henry

i?ve always used
c := ReadKey;
________________________________
William de Oliveira Ferreira
Bacharel em Sistemas de Informa??o

2011/11/18 Henry Vermaak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111118/aac81c91/attachment.html>

It seems I got that working. Actually the strange thing is, it should have been working right from the start.
And yes it is about the config of the terminal.

It was for the console window of the debugger. And that now forwards individual chars.

to expand on that, use the boolean function keypressed. Remember on IBM compatibles that function keys send 2 scan codes. The first, #0, to indicate a function key and not a normal key, and then the scan code for the actual keypress. This includes the edit keys (insert, delete, home, end, pgup, pgdn, and arrow keys).

Here is a code fragment for an example:

if keypressed then

   begin
         c := readkey;
         if c = #0 then
             begin
                   c := readkey;
                   case c of
                          #132 : doSomething;
                             .
                             .
                             .
                   end; {case c}
             end {if #0 is true}
        else
           begin
             case c of
                    #132 : doSomethingElse;
                             .
                             .
                             .
             end; {case c}
           end; {if #0 is false}
   end; {if keypressed}

This is a Turbo Pascal convention (and FPC), not a standard or UCSD Pascal convention. Remember that strings are not a standard type, either.

Try the example here:
http://www.freepascal.org/docs-html/rtl/keyboard/getkeyevent.html

I wonder if I could ask a related question. With this code

     ke := GetKeyEvent;
     kr := TKeyRecord(ke);
     Write('<', IntToHex(ke, 8), '>');
     Write('<', IntToHex(kr.KeyCode, 4), ' ', IntToHex(kr.ShiftState,
2), ' ', IntToHex(kr.Flags, 2), '>');
     WriteLn;

If I enter 1 1<cr> (three characters followed by enter) on x86 (little-endian, using 2.6.0) I get

<03000231><0231 00 03>
<03003920><3920 00 03>
<03000231><0231 00 03>
<0300240A><240A 00 03>

while on SPARC (big-endian, using 2.7.1) I get

<03000231><0300 02 31>
<03003920><0300 39 20>
<03000231><0300 02 31>
<0300240A><0300 24 0A>

Referring to
http://lazarus-ccr.sourceforge.net/docs/rtl/keyboard/tkeyrecord.html I would have thought that this should have been sorted inside the keyboard unit.

ke := GetKeyEvent; kr := TKeyRecord(ke);

The cast to TKeyRecord is wrong. You should use GetKeyEventFlags, GetKeyEventCode, GetKeyEventShiftState, etc to get the individual parts. They do fe. a (KeyEvent and $00FF0000) shr 16; which is endian safe.

Ludo

Thanks Ludo, I was anticipating that but this was the result of a quick-and-dirty late-night experiment which relied on http://lazarus-ccr.sourceforge.net/docs/rtl/keyboard/tkeyevent.html being correct: it explicitly says a typecast should work.