Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!ames!ads.com!killer!usenet
From: anders@verity.com (Anders Wallgren)
Newsgroups: comp.sys.mac.hardware
Subject: Re: Solution: swapping keys on extended keyboard
Message-ID: <1991Jan4.214437.6025@verity.com>
Date: 4 Jan 91 21:44:37 GMT
References: <1991Jan4.065438.19493@maverick.ksu.ksu.edu> <1991Jan4.184536.4581@verity.com>
Sender: usenet@verity.com (USENET News)
Reply-To: anders@verity.com (Anders Wallgren)
Organization: Verity, Inc., Mountain View, CA
Lines: 26
In-Reply-To: anders@verity.com (Anders Wallgren)

Unfortunately I spoke too soon.  My IIfx and Extended Keyboard II
didn't seem to want to pay attention to changes to the KMAP resource
(I even tried modifying the other ones to see if the new keyboard uses
a different one, but to no avail).

I did have some luck modifying the table-mappings in the KCHR
resource, though (I swapped the control and caps-lock mappings - just
hold down the modifier and select the table you want it to use).  The
down side here was that now the right control key also acted as a
shift-key.  I was prepared to live with this, since I never use it
anyway, but as it turns out, MacX (my main motivation for doing this
in the first place), ignores these mappings and uses its own (which it
should).

Having modified the table-mappings, most mac applications treated
the keys correctly, except for MicroEmacs, which had problems with
certain control-keys.  Also, the caps-lock light kept lighting up when
I pressed the caps-lock key that was now a control key.  I then tried
modifying the KMAP resource again, and the light stopped working
altogether. 

Back to square one...



anders