Groups | Search | Server Info | Login | Register


Groups > comp.os.os2.programmer.misc > #1894

Re: inoperative keyboard - analysis required

From Paul Edwards <mutazilah@gmail.com>
Newsgroups comp.os.os2.programmer.misc
Subject Re: inoperative keyboard - analysis required
Date 2024-03-04 18:47 +0800
Organization A noiseless patient Spider
Message-ID <us48s8$33oru$1@dont-email.me> (permalink)
References (3 earlier) <wOzEN.81901$6ePe.45424@fx42.iad> <uruja1$1onfe$1@dont-email.me> <%MREN.454297$c3Ea.430095@fx10.iad> <us0ulk$2b51j$1@dont-email.me> <us12kt$2bptd$1@dont-email.me>

Show all headers | View raw


On 03/03/24 13:42, Paul Edwards wrote:

> Even in the semi-worse case, there should always be a
> second character after ESC, so in my doscalls.c I should
> be able to read a second character, and then just have
> to translate two characters. The rest of the ANSI escape
> sequence can then go "under the radar" (no need to
> translate). It is very likely I just need to detect a
> double ESC and translate that.

It didn't work out like that. The escape was
still doubled up by PDPCLIB and I was about to
give up and do a full translation when I realized
I could provide a dummy (0) scancode and check
that in PDPCLIB and allow all the characters to
slide in "under the radar".

There's still an issue for people who may use x'e0'
for their national characters (issue may not exist
on PDOS), but for normal programming requirements
(ie pure ASCII), the new PDOS/386 at pdos.org handles
the raw reading now too.

BFN. Paul.

Back to comp.os.os2.programmer.misc | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 03:06 +0800
  Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 15:57 -0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 09:17 +0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:37 -0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 15:08 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:04 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 12:34 +0800
              Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 13:42 +0800
                Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-04 18:47 +0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:48 +0800
      Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:54 +0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 11:43 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 23:22 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 16:05 +0800
              Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:07 -0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:42 -0800

csiph-web