HeathField Strange Ideas!

[Sjouke Burry]

You need to get your tongue out of Keith's, well, you know...

Explain please, I have no idea what you are hinting at......

 

[Keith Thompson]

Indeed. The best advice for the OP was a redirect to a newsgroup
where his question could be dealt with by Unix experts. And that's
precisely what you supplied.

[SNIP]

Explain please, I have no idea what you are hinting at......

Please don't ask. KM is a notorious troll; his only intent was to be
insulting and crude. Please ignore him.q

 

[Ernie Wright]

If somebody asks how to detect a keypress, the first question is: "on
what OS, and using what connection between the keyboard and the program?"
If the answer is Windows it should be "conio" (I think, but I cannot
check because I have no access to window machines where that is viable).
If the answer is a system running X you better learn the interface to
capture X events in your window (and that is not exactly trivial).

The situation under Windows is much more like X (or really, the GUI
toolkits, e.g. GTK+, running on top of it). Keypress events are handled
in the callback attached to the currently active window. In character
mode (console) programs, Win32 provides a console API in which low-level
keypress events are retrieved by ReadConsoleInput().

conio was for DOS. It touched the hardware directly, through BIOS
interrupts and video memory writes.

I'm not sure what this says about the topicality question, but I suspect
people will read into it what they want.

- Ernie http://home.comcast.net/~erniew

 

[CBFalconer]

Explain please, I have no idea what you are hinting at......

McCormack is a known troll. Ignore it.

--

+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================

fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchinson

 

[Dave Vandervies]

The situation under Windows is much more like X (or really, the GUI
toolkits, e.g. GTK+, running on top of it). Keypress events are handled
in the callback attached to the currently active window.

That's a very odd way of spelling "A WM_KEYDOWN message appears in the
message queue for the thread that owns the window".

I'm sure the folks in comp.os.ms-windows.programmer.win32 would be
happy to discuss this in far more detail than the Mac, Unix, mainframe,
embedded, and platform-agnostic programmers who are reading CLC care to
read.


dave

 

[Ernie Wright]

That's a very odd way of spelling "A WM_KEYDOWN message appears in the
message queue for the thread that owns the window".

For readers who think conio might be current Windows practice, that's a
funny way of explaining where a WM_KEYDOWN is typically *handled*.

(sigh)

I can see why the regulars consider this kind of discussion radioactive.
I personally think the conversation would be enriched by the occasional
comparison between platforms among the experts here. Platform-specific
groups are too parochial for that, and general programming groups lack
the depth of C knowledge.

But I'm not going to tilt at that particular windmill.

I'm sure the folks in comp.os.ms-windows.programmer.win32 would be
happy to discuss this in far more detail than the Mac, Unix, mainframe,
embedded, and platform-agnostic programmers who are reading CLC care to
read.

Yes, no doubt they would.

- Ernie http://home.comcast.net/~erniew

 

[Richard Heathfield]

Ernie Wright said:

I can see why the regulars consider this kind of discussion
radioactive. I personally think the conversation would be enriched by
the occasional comparison between platforms among the experts here.

Frankly, I agree with you, with emphasis on the "would", alas. It is
very unfortunate that the cons outweigh the pros - but c'est la vie.

<snip>

 

[Malcolm McLean]

For readers who think conio might be current Windows practice, that's a
funny way of explaining where a WM_KEYDOWN is typically *handled*.

It's been replaced by conu.
However you still see conio in non-portable code posted by newbies, so that
makes it current practise.

I can see why the regulars consider this kind of discussion radioactive.
I personally think the conversation would be enriched by the occasional
comparison between platforms among the experts here. Platform-specific
groups are too parochial for that, and general programming groups lack
the depth of C knowledge.

I can be made topical. "How should we go about writing a portable C console
interface?" Really it's more for comp.std.c, but there is a certain amount
of overlap.

 

[jacob navia]

For readers who think conio might be current Windows practice, that's a
funny way of explaining where a WM_KEYDOWN is typically *handled*.

(sigh)

I can see why the regulars consider this kind of discussion radioactive.
I personally think the conversation would be enriched by the occasional
comparison between platforms among the experts here. Platform-specific
groups are too parochial for that, and general programming groups lack
the depth of C knowledge.

This would make this group less boring.

That could be dangerous...

But I'm not going to tilt at that particular windmill.

Of course not. If not you would be subject to the same insults
attacks, that I am.

Good decision.

 

[Mark McIntyre]

This would make this group less boring.

Oh look, more trolling from Jacob Trollmeister

Don't you ever get bored of being the village idiot?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Dik T. Winter]

> I can see why the regulars consider this kind of discussion radioactive.
> I personally think the conversation would be enriched by the occasional
> comparison between platforms among the experts here. Platform-specific
> groups are too parochial for that, and general programming groups lack
> the depth of C knowledge.

How many are expert in more than one platform? I am not among them.
For key presses, I know for many *nix* platforms how to do it (when it is
possible, which is not always the case).

This reminds me of a long time ago (actually the time when Unix came standard
with games and there were a lot of p.d. games for Unix). One of those had
(the fairly Unix standard) letters to move along some field (h = left,
j = down, k = up and l = right). In addition there was the period to say
stay at the place. In addition you had control symbols (^h, ^j, ^k and ^l)
to say move in that direction while it is safe to do so (i.e. you come not
in reach of enemies). A co-worker asked why ^. (i.e. cntrl-.) was not
implemented as stay while enemies move in and it is safe. Now for you to
answer why that was not implemented.

 

[Dik T. Winter]

> I can be made topical. "How should we go about writing a portable C console
> interface?" Really it's more for comp.std.c, but there is a certain amount
> of overlap.

This has a lot of undefined things in it. As I read it, I understand an
interface that can be included in a program so to interface with the
console where the user is currently touching the keys. To that the
answer is: it can only be done if the application is running on the
same computer that connects to the computer, and even then it is not
necessarily possible. In many cases the applications I use, and that
are consuming what I enter at the keyboard, are *not* running on the
machine where I am entering at the keyboard. With some windowing
systems it *is* possible in such cases, but that is not applicable to
my current situation. So, what is portable?

 

[Ernie Wright]

How many are expert in more than one platform?

That's precisely why I think there might be value in comparing notes.

in reach of enemies). A co-worker asked why ^. (i.e. cntrl-.) was not
implemented as stay while enemies move in and it is safe. Now for you to
answer why that was not implemented.

Presumably because there's no ASCII encoding for <^.>.

- Ernie http://home.comcast.net/~erniew

 

[Malcolm McLean]

This has a lot of undefined things in it. As I read it, I understand an
interface that can be included in a program so to interface with the
console where the user is currently touching the keys. To that the
answer is: it can only be done if the application is running on the
same computer that connects to the computer, and even then it is not
necessarily possible. In many cases the applications I use, and that
are consuming what I enter at the keyboard, are *not* running on the
machine where I am entering at the keyboard. With some windowing
systems it *is* possible in such cases, but that is not applicable to
my current situation. So, what is portable?

That's an obvious issue that a lot of people might not be aware of. You'd
generally assume that if the computer is physically connected to a keyboard,
and is receiving keystrokes from it, then it will also be possible to scan
the state of the keys. However that might not be true. How often is it not
true? My Beowulf runs in a virtual terminal, but it has curses. Not that
I've ever used it.

That's an example of how a discussion can be fruitful. However is it
topical? We are veering away from C and into virtual terminal protocols. It
mgith be a good thing or it might be a bad idea.

 

[Mark McIntyre]

That's precisely why I think there might be value in comparing notes.

Trouble is, the mechanism for doing (say) screen or hardware port IO
is typically so different between hardware and OS platforms that
comparison is probably meaningless.

And bear in mind that by far the commonest use of C is probably in
embedded systems with highly specialised IO interfaces.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Kelsey Bjarnason]

[snips]

That's an obvious issue that a lot of people might not be aware of. You'd
generally assume that if the computer is physically connected to a keyboard,
and is receiving keystrokes from it, then it will also be possible to scan
the state of the keys. However that might not be true. How often is it not
true?

Frequently.

I use, every single day, remote connections where the keyboard I'm working
on has no physical connection whatsoever to the machine I'm working with.

 

[Rob Kendrick]

Frequently.

I use, every single day, remote connections where the keyboard I'm working
on has no physical connection whatsoever to the machine I'm working with.

Even more simply; a bluetooth keyboard ;-)

(Semantics, I know.)

B.

 

[Walter Roberson]

This has a lot of undefined things in it. As I read it, I understand an
interface that can be included in a program so to interface with the
console where the user is currently touching the keys. To that the
answer is: it can only be done if the application is running on the
same computer that connects to the computer, and even then it is not
necessarily possible.

I'll add a little to the confusion -- and where there is confusion,
there is unlikely to be portability ;-)

On the great majority of modern desktop/laptop computers (and even of
those 15-ish years old), the keyboard does not emit a stream of
characters: instead it emits a stream of events, such as
"Left-shift pressed", "key #58 pressed", "key #58 pressed",
"left-shift released". Traditionally, if you are -directly- using
MS Windows, or a system with X Windows, a standardized version of those
events can be made available to the GUI (e.g., the GUI might receive
an encoding of "Keypad +" instead of "key #58"); even the raw events
are often available if you dig deep enough with those window systems.
And with X at least, the events can even be made available to remote
systems.

But there is no industry-standard method for programs to receive
these keyboard (or mouse) events; X is an official standard, used
by quite a number of systems, and MS Windows is a de-facto standard,
probably used by even more systems (in terms of sales, not in
terms of diversity), and they are not compatible: a program written
to interface to an X system would use very different calls than a
program written to interface to MS Windows. "Shims", to allow a
program coded for one event schema to be used with another, are
pretty uncommon too; certainly products such as Hummingbird's eXceed
exist, but that is a complete implementations of X, graphics and
all, not just a library or DLL that one can link against and gain
compatability cheaply.

What the C standard deals with is *character streams* (or byte
streams, if one is working in binary). Character streams are
the fully decoded output of keyboard events, with information
about modifiers and key presses and releases transformed into
ASCII or ISO 8859-1 or UTF-8 or Windows-1292 or the like.
There *are* standardized ways of handling many character-related
tasks (though tranforming between character sets could apparently
use some improvement at the C standard level), and there *are*
standardized ways of transmitting characters to remote systems,
or to virtualized systems.

Now, as events are what systems actually receive from keyboards,
it would be possible, in theory, to design an industry standard
(or at least "recognized" if not quite standardized) schema for
transmitting keyboard events between systems. Any such schema would,
of necessity, have to be flexible, to be able to gracefully
handle keyboards that lack certain capabilities (e.g., perhaps
the keyboard only emits key-up events and not key-down events
as well); the schema would also have to encompass systems that
deal strictly with fully-decoded character streams.


All this to address Dik's note that,

it can only be done if the application is running on the
same computer that connects to the computer

That is, my counter-argument is that it -can- (many times) be done
if the application is running on a -different- computer than the
keyboard is connected to; it is routinely done for X.


But, to emphasize for clarity: any schema that were developed
for dealing with (possibly-remote) keyboard events should *not*
(IMHO), be part of the C standard. Yes, it would be nice for
users of such a schema to be able to count on it being in place, but
on the other hand, I believe it would be too much of a burden upon
systems that cannot or should not use such a facility. And it
might start getting into issues such as key press timing;
pretty much anything to do with precision timing is outside the
realm of what C itself handles.

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> Presumably because there's no ASCII encoding for <^.>.

Indeed. Key-press events were not available. Otherwise it could have
been done.

 

[Richard Bos]

That's precisely why I think there might be value in comparing notes.

Only to prove that it can't be done, and where it can be done it's not
much use, perhaps. For example...

Presumably because there's no ASCII encoding for <^.>.

For example, no, that's not the reason, because there's no ASCII
encoding for ^A...^Z, either. There's an encoding commonly used on some
ASCII-based platforms, but it's not officially ASCII. If one wished, one
could easily couple control-. to any keycode desired; but it would be
rather more unportable than assuming ASCII, and also somewhat more
unportable than assuming the common encoding of ^A.

Richard