|
|
Post by George on Mar 6, 2022 12:22:26 GMT -5
Robert: This is a quite significant change, affecting many areas. And the KB support has oodles of 'wrinkles' as it is, just read through MainAKeyHook.
Are we really short of mappable keys? Do we want/need another 800 or so?
George
[ Comment? I haven't shot it down, just want to be sure it buys something worth the effort. ]
|
|
|
|
Post by George on Mar 12, 2022 13:59:59 GMT -5
Robert: Actually, after some thinking, it may be possible to have NumLock be the switch between two full KB mappings. I'm sure worms will crawl out if I attempt this, but it's easier than a partial solution. Two full mappings might be usefull for users who work in multiple languages, who knows?
George
|
|
|
|
Post by George on Mar 13, 2022 9:57:29 GMT -5
Robert: Simpler to invent a new (Passthru) -- (PassMain) ? to indicate use of whatever is in the 'normal' keymap, even if that is (Null). Usable only on the new secondary Keypad table.
I'd populate the whole 'new' Keymap with (PassMain) except the Numpad keys which would default to their keycaps (0-9, +, -, *, etc.) And all keys may then be suitably custom modified by the user using KEYMAP.
The less I fiddle with the KB table structure and contents, the better. It's layered already - Master Table -> Overlay with Users Table -> Create Working KB table. If I keep the new table separate, it should work.
George
|
|
|
|
Post by George on Mar 13, 2022 12:08:24 GMT -5
Yes, but you would be able to map KP - to whatever you want in either Numlock or non-Numlock mode. I'm only talking the initial defaults for the new table. Which will be (PassMain) for everything except the KP keys which will be set to their visible keycaps. This is to keep everything identical to the present UNTIL the user specifically uses KEYMAP to alter things.
|
|
|
|
Post by George on Mar 14, 2022 11:27:50 GMT -5
Robert:
There's already grunt code in the Keyboard hook to 'hard code' the NumLock version of KP keys. I didn't put that in willy-nilly, it was necessary to get things to work. With two KB tables, that grunt code would be removed.
I spent many hours getting that KB code straight, and it contains lots of 'wrinkles' that were found the hard way. Trust me, it's a very hairy area.
As far as initializing the new NumLock table, I'm not receptive to just populating it as a duplicate of the main one, since that means when a user wants to alter a key to work the same in both tables, they would have to do the update twice. I don't think that would fly. I think that's what you're getting at with the suggested (Main), or is that just your version of (PassMain)?
George
|
|
|
|
Post by George on Mar 14, 2022 13:07:23 GMT -5
Robert: Your (Main) and my (PassMain) are almost identical. Except I don't copy the (Main) values to the Numlock table EVER. The link back to the main table setting would be done by the Keyboard handler as a simple chain onward to the maintable's entry.
And if (Passthru) did work properly for the KP, then why did I have to stuff the following kludge into the keyboard handler?
'----- Another fudge for KeyPad handling
IF ISTRUE NumState THEN ' Try and overcome Keypad stupidities
IF KeyCode = &H6F THEN KeyLookup = CHR$(&HBF) + " ..." ' / Key
IF KeyCode = &H6A THEN KeyLookup = CHR$(&H38) + " S.." ' * Key
IF KeyCode = &H6D THEN KeyLookup = CHR$(&HBD) + " ..." ' - Key
IF KeyCode = &H67 THEN KeyLookup = CHR$(&H37) + " ..." ' 7 Key
IF KeyCode = &H68 THEN KeyLookup = CHR$(&H38) + " ..." ' 8 Key
IF KeyCode = &H69 THEN KeyLookup = CHR$(&H39) + " ..." ' 9 Key
IF KeyCode = &H64 THEN KeyLookup = CHR$(&H34) + " ..." ' 4 Key
IF KeyCode = &H65 THEN KeyLookup = CHR$(&H35) + " ..." ' 5 Key
IF KeyCode = &H66 THEN KeyLookup = CHR$(&H36) + " ..." ' 6 Key
IF KeyCode = &H61 THEN KeyLookup = CHR$(&H31) + " ..." ' 1 Key
IF KeyCode = &H62 THEN KeyLookup = CHR$(&H32) + " ..." ' 2 Key
IF KeyCode = &H63 THEN KeyLookup = CHR$(&H33) + " ..." ' 3 Key
IF KeyCode = &H60 THEN KeyLookup = CHR$(&H30) + " ..." ' 0 Key
IF KeyCode = &H6B THEN KeyLookup = CHR$(&HBB) + " S.." ' + Key
IF KeyCode = &H6E THEN KeyLookup = CHR$(&HBE) + " ..." ' . Key
END IF '
Really, trust me, I can make this work.
George
|
|
|
|
Post by George on Mar 14, 2022 14:29:01 GMT -5
Robert: At this point I have no idea when/where/why the KP kludge became needed. It was just another of the many peculiarities of KB handling that I stumbled through way back then. It was the same with foreign keyboards, dead keys, repeat handling etc. It was all experimenting, debug tracing etc. The KB should be simple and logical, but with MS's development history it is anything but, it's a zoo.
George
|
|
|
|
Post by George on Mar 23, 2022 8:26:41 GMT -5
Robert: I have been poking about here for the last week or so. After re-learning how the KB tables and lookup are done (since it was written many, many years ago) I thought I had a way to accomplish this. After a lot of effort, I hit a very large brick wall.
Without a major re-write of the whole thing, I can't do it. Shoe-horning in a 2nd table, which seemed feasible, just won't work.
So I'm afraid I'm shelving this idea, sorry.
George
|
|
