Hello all,

I've set the console input to raw so I can see keys coming in when they are
pressed.

For that I've been writing a big "switch ... case" to parse the multi-byte
keystrokes into "records" that than can be easily worked with or discarded.

As this parsing needs to be done by pretty-much every console-based program
which wants to do any kind of interactive stuff I was wondering if this
perhaps is already part of Linux ...

If it is (and thats still a big "if"), where can I find it ?

Second question : How do I check for modifier keys (like alt, shift, ctrl)
on the pressed keys or seperatily ? I would like to be able to, as an
example, catch a ctrl-cursor-left as well as a normal or a shift-curor-left.

Regards,
Rudy Wieser

On 2023-06-25 7:45 PM, R.Wieser wrote:
> Hello all,
>
> I've set the console input to raw so I can see keys coming in when they are
> pressed.
>
> For that I've been writing a big "switch ... case" to parse the multi-byte
> keystrokes into "records" that than can be easily worked with or discarded.
>
> As this parsing needs to be done by pretty-much every console-based program
> which wants to do any kind of interactive stuff I was wondering if this
> perhaps is already part of Linux ...
>
> If it is (and thats still a big "if"), where can I find it ?

curses library

> Second question : How do I check for modifier keys (like alt, shift, ctrl)
> on the pressed keys or seperatily ? I would like to be able to, as an
> example, catch a ctrl-cursor-left as well as a normal or a shift-curor-left.

Alf,

>> If it is (and thats still a big "if"), where can I find it ?
>
> curses library

Thats was the first thing I checked for, but it does not seem to be part of
my "bullseye lite" installation ...

But assuming I go and install it, its "man" page shows that it has got quite
a number of functions. Any suggestions to where to look how to use it for
what I described ?

Regards,
Rudy Wieser

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 2023-06-25 7:45 PM, R.Wieser wrote:
>> Hello all,
>>
>> I've set the console input to raw so I can see keys coming in when
>> they are pressed.
>>
>> For that I've been writing a big "switch ... case" to parse the
>> multi-byte keystrokes into "records" that than can be easily worked
>> with or discarded.
>>
>> As this parsing needs to be done by pretty-much every console-based
>> program which wants to do any kind of interactive stuff I was
>> wondering if this perhaps is already part of Linux ...
>>
>> If it is (and thats still a big "if"), where can I find it ?
>
> curses library

curses takes over the entire (text / terminal) screen, keeping track
of what character is shown at each location and using minimal output to
update it as needed.

If that's what you want, that's great, but as far as I can tell curses
is not suitable for, for example, detecting the user pressing an arrow
key *without* controlling the whole screen.

The GNU readline library may be closer, but it's at a higher level; it
handles things like arrow key input, but it doesn't give you information
like "the user just pressed up-arrow". In the past, I've tried and
failed to find a library that gives access to that kind of information.
(The terminfo database gives you the character sequences corresponding
to the various keys, but I don't think it provides code to detect them
on input.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

R.Wieser wrote:
> Hello all,
>
> I've set the console input to raw so I can see keys coming in when they are
> pressed.
>
> For that I've been writing a big "switch ... case" to parse the multi-byte
> keystrokes into "records" that than can be easily worked with or discarded.
>
> As this parsing needs to be done by pretty-much every console-based program
> which wants to do any kind of interactive stuff I was wondering if this
> perhaps is already part of Linux ...
>
> If it is (and thats still a big "if"), where can I find it ?

On Linux (strictly speaking, on a GNU system) specifically, try readline
function.

AFAIK, it is available everywhere bash is so your system should already
have it. Try "man readline".

>
> Second question : How do I check for modifier keys (like alt, shift, ctrl)
> on the pressed keys or seperatily ? I would like to be able to, as an
> example, catch a ctrl-cursor-left as well as a normal or a shift-curor-left.
>
> Regards,
> Rudy Wieser
>
>

HTH
-Pavel

"R.Wieser" <address@is.invalid> writes:
>Hello all,
>
>I've set the console input to raw so I can see keys coming in when they are
>pressed.
>
>For that I've been writing a big "switch ... case" to parse the multi-byte
>keystrokes into "records" that than can be easily worked with or discarded.
>
>As this parsing needs to be done by pretty-much every console-based program
>which wants to do any kind of interactive stuff I was wondering if this
>perhaps is already part of Linux ...
>
>If it is (and thats still a big "if"), where can I find it ?

$ man console_ioctl

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:

> R.Wieser wrote:
>> Hello all,
>> I've set the console input to raw so I can see keys coming in when they
>> are
>> pressed.
>> For that I've been writing a big "switch ... case" to parse the
>> multi-byte
>> keystrokes into "records" that than can be easily worked with or discarded.
>> As this parsing needs to be done by pretty-much every console-based
>> program
>> which wants to do any kind of interactive stuff I was wondering if this
>> perhaps is already part of Linux ...
>> If it is (and thats still a big "if"), where can I find it ?
>
> On Linux (strictly speaking, on a GNU system) specifically, try readline
> function.
>
> AFAIK, it is available everywhere bash is so your system should already
> have it. Try "man readline".

I don't know if it's what's wanted but the rlwrap program is not as well
know as it should be. Essentially it "wraps" any interactive program
with a readline-driven editing, completion and history interface.

--
Ben.

scott@slp53.sl.home (Scott Lurndal) writes:
> "R.Wieser" <address@is.invalid> writes:
>>I've set the console input to raw so I can see keys coming in when they are
>>pressed.
>>
>>For that I've been writing a big "switch ... case" to parse the multi-byte
>>keystrokes into "records" that than can be easily worked with or discarded.
>>
>>As this parsing needs to be done by pretty-much every console-based program
>>which wants to do any kind of interactive stuff I was wondering if this
>>perhaps is already part of Linux ...
>>
>>If it is (and thats still a big "if"), where can I find it ?
>
> $ man console_ioctl

I believe that only applies to the Linux system console (the text-only
interface you typically get by typing Ctrl-Alt-N, where N is a small
integer). I know the OP wrote "console", but I suspect they're looking
for something that works on a terminal emulator.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>> On 2023-06-25 7:45 PM, R.Wieser wrote:
>>> Hello all,
>>>
>>> I've set the console input to raw so I can see keys coming in when
>>> they are pressed.
>>>
>>> For that I've been writing a big "switch ... case" to parse the
>>> multi-byte keystrokes into "records" that than can be easily worked
>>> with or discarded.
>>>
>>> As this parsing needs to be done by pretty-much every console-based
>>> program which wants to do any kind of interactive stuff I was
>>> wondering if this perhaps is already part of Linux ...
>>>
>>> If it is (and thats still a big "if"), where can I find it ?
>>
>> curses library
>
> curses takes over the entire (text / terminal) screen, keeping track
> of what character is shown at each location and using minimal output to
> update it as needed.
>
> If that's what you want, that's great, but as far as I can tell curses
> is not suitable for, for example, detecting the user pressing an arrow
> key *without* controlling the whole screen.
>
> The GNU readline library may be closer, but it's at a higher level; it
> handles things like arrow key input, but it doesn't give you information
> like "the user just pressed up-arrow". In the past, I've tried and
> failed to find a library that gives access to that kind of information.

These codes are terminal-specific but basic things like up-arrww are
more or less standardized in ANSI terminal.

Unsure if this is what you were looking for, but works for me:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <readline/readline.h>

int
up_callback(int count, int key) {
printf ("the user just pressed up-arrow\n");
return 0;
}

int
main(int argc, char *argv[])
{ rl_bind_keyseq ("\\e[A", up_callback);
free(readline("press a button > "));

printf("\n");

return 0;
}

> (The terminfo database gives you the character sequences corresponding
> to the various keys, but I don't think it provides code to detect them
> on input.)
>

HTH
-Pavel

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
> Keith Thompson wrote:
>> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>> On 2023-06-25 7:45 PM, R.Wieser wrote:
>>>> Hello all,
>>>>
>>>> I've set the console input to raw so I can see keys coming in when
>>>> they are pressed.
>>>>
>>>> For that I've been writing a big "switch ... case" to parse the
>>>> multi-byte keystrokes into "records" that than can be easily worked
>>>> with or discarded.
>>>>
>>>> As this parsing needs to be done by pretty-much every console-based
>>>> program which wants to do any kind of interactive stuff I was
>>>> wondering if this perhaps is already part of Linux ...
>>>>
>>>> If it is (and thats still a big "if"), where can I find it ?
>>>
>>> curses library
>> curses takes over the entire (text / terminal) screen, keeping track
>> of what character is shown at each location and using minimal output to
>> update it as needed.
>> If that's what you want, that's great, but as far as I can tell
>> curses
>> is not suitable for, for example, detecting the user pressing an arrow
>> key *without* controlling the whole screen.
>> The GNU readline library may be closer, but it's at a higher level;
>> it
>> handles things like arrow key input, but it doesn't give you information
>> like "the user just pressed up-arrow". In the past, I've tried and
>> failed to find a library that gives access to that kind of information.
>
> These codes are terminal-specific but basic things like up-arrww are
> more or less standardized in ANSI terminal.

These days, yes, mostly. Termcap, terminfo, and [n]curses were
developed when there were a wide variety of terminals (not just
emulators) with incompatible control sequences. Today if you assume
VT100-compatible codes, you can probably get away with it. But there
are still a lot of libraries that support other terminal types.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith,

> curses takes over the entire (text / terminal) screen
....
> but as far as I can tell curses is not suitable for, for example,
> detecting the user pressing an arrow key *without* controlling
> the whole screen.

That indeed makes it pretty-much unusable for me.

> In the past, I've tried and failed to find a library that gives access
> to that kind of information.

IOW, it probably doesn't exist and I need to create my own solution for it.
You telling me that saves me a /lot/ of further googeling. Thanks.

> (The terminfo database gives you the character sequences corresponding
> to the various keys, but I don't think it provides code to detect them
> on input.)

Its something to look at and see if it can be used to do the reverse.

Thanks for the info and heads-up.

Regards,
Rudy Wieser

Pavel,

> On Linux (strictly speaking, on a GNU system) specifically, try readline
> function.

The problem with that is that I need the keys at the moment they are pressed
(and released ?), not only after "enter" is pressed.

Regards,
Rudy Wieser

Scott,

> $ man console_ioctl

Yeah, I found that one too.

Correct me if I'm wrong, but that looks like it only works for the local
keyboard and won't be of much use in a remote session ...

Regards,
Rudy Wieser

Ben,

> Essentially it "wraps" any interactive program with a
> readline-driven editing, completion and history interface.

Thats pretty-much the opposite of what I currently want/need.

I'm trying to write something thats interactive - For example, imagine a
list of items you can move thru using the cursor keys and select pressing
the spacebar.

Regards,
Rudy Wieser

Keith,

> I know the OP wrote "console", but I suspect they're looking
> for something that works on a terminal emulator.

Nope, not an emulator. As said, "bullseye lite" doesn't have a GUI.

As for the difference between a "console" and a "terminal" ? I must say
that its not quite clear (read: confusing) to me , as it seems to be used
interchangably. If you have a good description about the differences
between a "console" and a "terminal" than I would like to hear about it.

Simply said, to me a "console" is the text-based interface you get on a
'puter thats executing the commands. A "terminal" is the program you use
to remotely(?) connect to such a console.

Regards,
Rudy Wieser

Hi Rudy,

Am 26.06.23 um 09:11 schrieb R.Wieser: >> Essentially it "wraps" any
interactive program with a
>> readline-driven editing, completion and history interface.
>
> Thats pretty-much the opposite of what I currently want/need.
>
> I'm trying to write something thats interactive - For example, imagine a
> list of items you can move thru using the cursor keys and select pressing
> the spacebar.

Then you might want something even more higher level than curses. For
example, CDK gives you widgets in order to program a GUI that runs in
the terminal: https://github.com/lnkgyv/cdk_examples

If you are actually looking to do it on your own, you might want to look
at termcap, which tells you the raw codes involved:
https://www.gnu.org/software/termutils/manual/termcap-1.3/html_node/termcap_37.html

Christian

"R.Wieser" <address@is.invalid> writes:
> Keith,
>
>> I know the OP wrote "console", but I suspect they're looking
>> for something that works on a terminal emulator.
>
> Nope, not an emulator. As said, "bullseye lite" doesn't have a GUI.
>
> As for the difference between a "console" and a "terminal" ? I must say
> that its not quite clear (read: confusing) to me , as it seems to be used
> interchangably. If you have a good description about the differences
> between a "console" and a "terminal" than I would like to hear about it.
>
> Simply said, to me a "console" is the text-based interface you get on a
> 'puter thats executing the commands. A "terminal" is the program you use
> to remotely(?) connect to such a console.

The term "console", on Unix-like systems, typically refers to the system
console, sometimes accessed via /dev/console, while a "terminal" is a
more general term for a text-based interface, usually accessed via
/dev/tty* or similar. (A typical user might never see the console.)

The details beyond that are probably off-topic here.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

"R.Wieser" <address@is.invalid> writes:
> Keith,
>
>> I know the OP wrote "console", but I suspect they're looking
>> for something that works on a terminal emulator.
>
> Nope, not an emulator. As said, "bullseye lite" doesn't have a GUI.
>
> As for the difference between a "console" and a "terminal" ? I must say
> that its not quite clear (read: confusing) to me , as it seems to be used
> interchangably. If you have a good description about the differences
> between a "console" and a "terminal" than I would like to hear about it.
>
> Simply said, to me a "console" is the text-based interface you get on a
> 'puter thats executing the commands. A "terminal" is the program you use
> to remotely(?) connect to such a console.

The term "console", on Unix-like systems, typically refers to the system
console, sometimes accessed via /dev/console, while a "terminal" is a
more general term for a text-based interface, usually accessed via
/dev/tty* or similar. (A typical user might never see the console.)

Historically, you'd have a single system console (hardware terminal)
connected directly to the computer, and one or more remote terminals for
users. More modern interfaces (virtual consoles and terminal emulators)
are based on that.

The details beyond that are probably off-topic here, if they aren't already.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

"R.Wieser" <address@is.invalid> writes:
>> On Linux (strictly speaking, on a GNU system) specifically, try readline
>> function.
>
> The problem with that is that I need the keys at the moment they are pressed
> (and released ?), not only after "enter" is pressed.

You might take a look at the readline source code to see how it does
that. It's certainly able to recognize the user pressing up-arrow
(which typically sends Esc-[-A) and acting on it immediately,
even if it doesn't expose that ability directly to the user.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Monday, June 26, 2023 at 1:45:54 AM UTC+8, R.Wieser wrote:
> Hello all,
>
> I've set the console input to raw so I can see keys coming in when they are
> pressed.
>
> For that I've been writing a big "switch ... case" to parse the multi-byte
> keystrokes into "records" that than can be easily worked with or discarded.
>
> As this parsing needs to be done by pretty-much every console-based program
> which wants to do any kind of interactive stuff I was wondering if this
> perhaps is already part of Linux ...
>
> If it is (and thats still a big "if"), where can I find it ?
>
> Second question : How do I check for modifier keys (like alt, shift, ctrl)
> on the pressed keys or seperatily ? I would like to be able to, as an
> example, catch a ctrl-cursor-left as well as a normal or a shift-curor-left.
>
> Regards,
> Rudy Wieser

/* Copyright is licensed by GNU LGPL, see file COPYING. by I.J.Wang 2005

Raw mode TTY for keyboard input.

Build: g++ t_kb.cpp -lwy
*/
#include <Wy.stdio.h> // for cin,cout,cerr
#include <Wy.termios.h>
#include <Wy.unistd.h>

using namespace Wy;

// TTY i/o (raw mode terminal)
// RawTerm changes tty attributes so that we can read key stroke without press ENTER
//
// Warning: Many virtual members of ChrFile are not reimplemented for simplicity.
//
class RawTerm : public ChrFile {
Termios m_ptio; // Previous(original) termios setting
public:
WY_DECL_REPLY;
RawTerm() {};
RawTerm(const char*, int);
~RawTerm();
Errno getch(char&);
Errno write(const char);
Errno write(const char*);
} static mtty("/dev/tty",O_RDWR);

RawTerm::RawTerm(const char* pathname, int flag)
: ChrFile(pathname,flag)
{ Errno r=tcflush(*this,TCIFLUSH);
if(r!=Ok) {
WY_THROW( Reply(r) );
}
if((r=tcgetattr(*this,m_ptio))!=Ok) {
WY_THROW( Reply(r) );
}
try {
// Set the terminal mode
//
Termios ntio(m_ptio);
ntio.iflag_and(~(BRKINT| ICRNL| IXON| INPCK | ISTRIP));
ntio.lflag_and(~(ICANON| ECHO| ISIG| TOSTOP| IEXTEN));
ntio.oflag_and( ~(OPOST) );
ntio.cflag_or( CS8 );
ntio.cc_VMIN(1);
ntio.cc_VTIME(0);
if((r=tcsetattr(*this,TCSANOW,ntio))!=Ok) {
WY_THROW( Reply(r) );
}

// Read back check
Termios tmptio;
if((r=tcgetattr(*this,tmptio))!=Ok) {
WY_THROW( Reply(r) );
}

// Omitted: Check termios setting accepted or not
}
catch(const Termios::Reply& e) {
WY_THROW( Reply(r) );
};
};

RawTerm::~RawTerm()
{ // If *this is default, these functions just fail (no effect for any device)
Errno r;
r=tcflush(*this,TCIFLUSH);
r=tcsetattr(*this,TCSANOW,m_ptio);
};

/ Get one char from terminal
//
Errno RawTerm::getch(char& ch)
{ Errno r;
size_t n;
if((r=ChrFile::read(&ch,sizeof(ch),n))!=Ok) {
WY_RETURN(r);
}
if(n==0) {
WY_RETURN(EIO);
}
return r;
};
Errno RawTerm::write(const char ch)
{ Errno r;
size_t n;
if((r=ChrFile::write(&ch,sizeof(ch),n))!=Ok) {
WY_RETURN(r);
}
if(n!=1) {
WY_RETURN(EIO);
}
return r;
};
Errno RawTerm::write(const char* str)
{ if(str==NULL) {
WY_RETURN(EFAULT);
}
const size_t slen=Wy::strlen(str);
Errno r;
size_t n;
if((r=ChrFile::write(str,slen,n))!=Ok) {
WY_RETURN(r);
}
if(n!=slen) {
WY_RETURN(EIO);
}
return r;
};
int main(int, char* [])
try {

Errno r;

if((r=mtty.write("中文"))!=Ok) {
WY_THROW(r);
}
for(;;) {
char ch;
if((r=mtty.getch(ch))!=Ok) {
WY_THROW(r);
}
if((ch=='q')||(ch=='Q')) {
break;
}
/* if((r=mtty.write(ch))!=Ok) {
WY_THROW(r);
}*/
cout << (unsigned char)ch << ',';
}
return 0;
} catch(const Errno& e) {
cerr << wrd(e) << WY_ENDL;
return e.c_errno();
} catch(...) {
cerr << "main caught(...)" WY_ENDL;
throw;
};

----------------------------------
[]$ ./a.out
中文27,91,51,126,27,91,51,59,50,126,27,91,51,59,53,126,27,91,51,59,51,126, // keystroke: del, sh-del, ctrl-del, alt-del

Op 26.jun..2023 om 09:21 schreef R.Wieser:
> Keith,
>
>> I know the OP wrote "console", but I suspect they're looking
>> for something that works on a terminal emulator.
>
> Nope, not an emulator. As said, "bullseye lite" doesn't have a GUI.
>
> As for the difference between a "console" and a "terminal" ? I must say
> that its not quite clear (read: confusing) to me , as it seems to be used
> interchangably. If you have a good description about the differences
> between a "console" and a "terminal" than I would like to hear about it.
>
> Simply said, to me a "console" is the text-based interface you get on a
> 'puter thats executing the commands. A "terminal" is the program you use
> to remotely(?) connect to such a console.
>
Console for Linux is normally used for the console which uses a keyboard
directly connected to the computer, e.g. with USB, or PS2.

A terminal is more generic. E.g., originally terminals where connected
with a serial line to a computer ad the terminal did the interpretation
of the keyboard. This made it impossible to detect certain keypresses,
such as Ctrl, Shift, etc. The terminal in such a case does not send e.g.
a 'Shift' press, an 'a' press, an 'a' release and a 'Shift' release, but
it sends an uppercase 'A'.
Therefore, your request to detect pressing and releasing keys is not
possible for generic terminal software.

Op 26.jun..2023 om 12:31 schreef Fred. Zwarts:
> Op 26.jun..2023 om 09:21 schreef R.Wieser:
>> Keith,
>>
>>> I know the OP wrote "console", but I suspect they're looking
>>> for something that works on a terminal emulator.
>>
>> Nope, not an emulator.  As said, "bullseye lite" doesn't have a GUI.
>>
>> As for the difference between a "console" and a "terminal" ?   I must say
>> that its not quite clear (read: confusing) to me , as it seems to be used
>> interchangably.   If you have a good description about the differences
>> between a "console" and a "terminal" than I would like to hear about it.
>>
>> Simply said, to me a "console" is the text-based interface you get on a
>> 'puter thats executing the commands.   A "terminal" is the program you
>> use
>> to remotely(?) connect to such a console.
>>
> Console for Linux is normally used for the console which uses a keyboard
> directly connected to the computer, e.g. with USB, or PS2.
>
> A terminal is more generic. E.g., originally terminals where connected
> with a serial line to a computer ad the terminal did the interpretation
> of the keyboard. This made it impossible to detect certain keypresses,
> such as Ctrl, Shift, etc. The terminal in such a case does not send e.g.
> a 'Shift' press, an 'a' press, an 'a' release and a 'Shift' release, but
> it sends an uppercase 'A'.
> Therefore, your request to detect pressing and releasing keys is not
> possible for generic terminal software.

And, of course, with software keyboards on a touch screen, the situation
is again completely different. Generic terminal software hides such
differences, but that limits the possible operations.

Keith,

> The term "console", on Unix-like systems, typically refers to the
> system console, sometimes accessed via /dev/console, while a "terminal"
> is a more general term for a text-based interface, usually accessed via
> /dev/tty* or similar. (A typical user might never see the console.)

As I said, the difference between them is /at best/ confusing. That you
than introduce "system console" without offering any explanation to it does
not help either. :-|

I found a link which says that all things are terminals, and that a console
is just a special one (your "system console").

In that case I'm working on/in the system console.

Though I'm going to have a hard time remembering that ALT F1 is a console,
but that ALT F2...F6 are terminals (I probably, likely won't. Too little,
if any, distinction).

And it doesn't help that I have a couple of WYSE WY60 terminals standing
behind me. :-)

Regards,
Rudy Wieser

Keith,

> You might take a look at the readline source code to see how it
> does that. It's certainly able to recognize the user pressing
> up-arrow (which typically sends Esc-[-A) and acting on it
> immediately, even if it doesn't expose that ability directly
> to the user.

As mentioned in my initial post, I have already switched the console input
to "raw", and as such I can see bytes coming in when I press keys. Thats
not the problem.

What is is turning those streams of bytes into individual keystrokes. I can
and already have parsed most keys for the "$TERM=linux" environment, but
would like *NOT* to use my own code if something build-in is available - and
getting support for other $TERM environments for free. :-)

Regards,
Rudy Wieser

Wij,

[snip code]

Thank you. Looking at the code I'm going to assume that receiving CTRL, ALT
and SHIFT modifier keys too is just a setting added to the "ntio.iflag"
field. I'll just have to check/find out which one it is. :-)

Regards,
Rudy Wiesr