Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1781 > unrolled thread

Detecting Keyboard types...

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Detecting Keyboard types... Gazza <usenet@garethlock.com> - 2012-06-06 07:34 -0700
    Re: Detecting Keyboard types... Martin Wuerthner <spamtrap@mw-software.com> - 2012-06-06 18:33 +0200
      Re: Detecting Keyboard types... Gazza <usenet@garethlock.com> - 2012-06-06 11:07 -0700
        Re: Detecting Keyboard types... jgharston <jgh@arcade.demon.co.uk> - 2012-06-06 17:38 -0700
          Re: Detecting Keyboard types... Gazza <usenet@garethlock.com> - 2012-06-07 01:29 -0700
            Re: Detecting Keyboard types... Gazza <usenet@garethlock.com> - 2012-06-08 09:04 -0700
    Re: Detecting Keyboard types... Gazza <usenet@garethlock.com> - 2012-06-06 09:39 -0700

#1781 — Detecting Keyboard types...

This is another issue with my keyboard handler library (eventually to
become the keyboard handler for the port of UMoria I'm writing). I'm
finding that the mappings for the old Archimedes etc keyboards are
different to those of the more modern PC type keyboards. At the
moment, I'm using a long-winded look-up table, which still isn't
catching all differences.

I guess I'm asking whether there is either a better way of doing it
than this, (OS call etc.) or is there an easy way to detect the
keyboard type on the fly and macro in the appropriate differences.

Thanks in advance...

[toc] | [next] | [standalone]

#1782

In message <c0136566-badf-433d-a1bd-8465bbad6446@w24g2000vby.googlegro 
ups.com>
          Gazza <usenet@garethlock.com> wrote:

> This is another issue with my keyboard handler library (eventually to
> become the keyboard handler for the port of UMoria I'm writing). I'm
> finding that the mappings for the old Archimedes etc keyboards are
> different to those of the more modern PC type keyboards. At the
> moment, I'm using a long-winded look-up table, which still isn't
> catching all differences.

> I guess I'm asking whether there is either a better way of doing it
> than this, (OS call etc.) or is there an easy way to detect the
> keyboard type on the fly and macro in the appropriate differences.

It really looks like you are trying to reinvent the wheel here. The OS 
(or more accurately, the keyboard driver) knows about keyboard 
layouts, and even more so, it also knows about locale settings, which 
you have not addressed yet. If you decided to bypass all that and scan 
physical keys, you would also have to deal with the fact that the key 
labelled "Q" on a UK keyboard produces the letter "A" on a machine 
with the keyboard driver set to French, and the key labelled "Y" 
produces the letter "Z" on my machine with the keyboard driver set to 
German.

If your game says that Ctrl+Z does something, then users expect to be 
able to enter Ctrl+Z in the usual way as everywhere else. That means, 
that on my machine I hold down Ctrl and press the key to the right of 
"T" and the keyboard driver maps that to Ctrl+Z correctly.

So, you had better forget about basing your input method on scanning 
physical keys. Simply process the character codes you get from the 
standard RISC OS input stream, which gives you a specific character 
code for Ctrl+Z, and there is no need for you to worry which physical 
keys were pressed in order to generate it. The OS deals with all that. 
If you want to detect the difference between Ctrl+Z and Ctrl+Shift+Z, 
which both result in the same character code, you just need to scan 
the state of the Shift key, which has the same internal key number 
everywhere (with the usual caveat about potential timing differences 
between the user pressing the keys and your program receiving the 
input character).

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1784

Thanks for the reply Martin...

What I'm trying to implement primarily is case-sensitive CTRL combos
and CTRL combos with top-bit set characters eg CTRL+{ for example. So
what I need is some way of getting the PRINTable portion of the combo.
If there's a better way than a giant LUT then I'm all ears.

[toc] | [prev] | [next] | [standalone]

#1786

Gazza wrote:
> What I'm trying to implement primarily is case-sensitive CTRL combos

So... Set CapsLock On, press Ctrl-A gives a different action
to Set CapsLock Off, press Ctrl-A ? DeepKey will give you that,
FNdeep_get AND ((1<<20) OR &1FF) will give &100001 or &1 respectively.

> and CTRL combos with top-bit set characters eg CTRL+{ for example. So

Ctrl-£ and Ctrl-Euro ? I'm surprised anything would want to
tell them apart from £ and Euro. But, again, DeepKey would tell
them apart, but on my A5000 Ctrl-£ goes not generate a keypress,
otherwise FNdeep_get AND ((1<<22) OR &1FF) would give &A3 for £
and &4000A3 for Ctrl-£.

JGH

[toc] | [prev] | [next] | [standalone]

#1787

On Jun 7, 1:38 am, jgharston <j...@arcade.demon.co.uk> wrote:
> Gazza wrote:
> > What I'm trying to implement primarily is case-sensitive CTRL combos
>
> So... Set CapsLock On, press Ctrl-A gives a different action
> to Set CapsLock Off, press Ctrl-A ? DeepKey will give you that,
> FNdeep_get AND ((1<<20) OR &1FF) will give &100001 or &1 respectively.
>
> > and CTRL combos with top-bit set characters eg CTRL+{ for example. So
>
> Ctrl-£ and Ctrl-Euro ? I'm surprised anything would want to
> tell them apart from £ and Euro. But, again, DeepKey would tell
> them apart, but on my A5000 Ctrl-£ goes not generate a keypress,
> otherwise FNdeep_get AND ((1<<22) OR &1FF) would give &A3 for £
> and &4000A3 for Ctrl-£.
>
> JGH

I'm looking at this in completely the wrong way, aren't I... What I
need to do is to use the ASCII code and apply an offset to get a
displayable character and check the CTRL or SHIFT bit where just
adding the offset would cause a conflict...

DUH!!!

Will get onto this when I next have the time... Probably Friday.

[toc] | [prev] | [next] | [standalone]

#1794

I'm considering this post closed as I have already implemented the
intended functionality in an entirely different way.

[toc] | [prev] | [next] | [standalone]

#1783

Already answered my own question in regards to obtaining keyboard
type...

SYS"OS_InstallKeyHandler",1 TO type%

Still looking for a better way of obtaining an ASCII code from a scan-
code though.

Will keep looking.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web