|
Post by George on Dec 3, 2023 14:00:37 GMT -5
I do remember having the source. I remember browsing it out of curiosity.
George
|
|
|
Post by Robert on Dec 3, 2023 20:32:57 GMT -5
I have revised the KeyboardTest source to make it document formerly "unknown" keys, but when I tried to email it to you your Gmail account blocked it.
[ should have mentioned it was a .ZIP with the .EXE in it too. ]
Suggestions?
R
|
|
|
Post by George on Dec 4, 2023 13:22:07 GMT -5
Robert: Yeah, GMail can be a pain at times. It can't be that big, attach it to a forum post. Source is public anyway.
George
|
|
|
Post by George on Dec 4, 2023 15:47:14 GMT -5
Robert: I've been playing with adding the OEM extensions to Kbd mapping, it gets uglier very quickly. Nothing to do with the upgrade migration, just the interplay of loading the defaults, handling an initial startup, and then the User overrides etc. It's extremely hard to add new scancodes to the existing structure. Basic problem is that user overrides are just that, overrides to the existing structure. There is no existing method to have user overrides ADD new scancodes.
Yes, that's possible, but bolting it onto the existing stuff and coping with keeping everyone's Kbd customization is becoming a 'bridge too far'.
George
|
|
|
Post by Robert on Dec 4, 2023 15:47:37 GMT -5
Kbd-Test.zip (85.63 KB) Here is everythingDon't use these files except for review. I have been updating them, and I'm not finished yet. But, I was able to compile the old source and it behaves like the current EXE so I feel confident I have the right one. R
|
|
|
Post by Robert on Dec 4, 2023 15:50:15 GMT -5
George, one thing to consider is that a scancode, and a VK code, are just 8-bit values. You can only have 256 of each. If your current design is indexed via VK codes, you could change it so that it always defined 256 entries, only that many of them would be null entries. That would avoid the hassle of adding new ones, since there would never be more than 256.
R
|
|
|
Post by George on Dec 5, 2023 10:29:26 GMT -5
Robert: Currently the lookup is not done by indexing, the scancode/VKCode (forget which) is paired with the SCA stuff and is looked up together. Combinations that are unused (i.e. (Null) ) are not even in the lookup table. I certainly do not want to get into revising the KB Hook routine and all the existing KB Table setup to move to an indexing style; that would be way too disruptive.
My big problem right now is that the user customization saved by KEYMAP does NOT contain the key/scan codes, only the 8 overrides for each key. And they basically match 1 for 1 with the 107 item KeyMaster table, which has everything in it. Ignoring migration of user data, adding to the KeyMaster table is a nuisance, but that's already done in my 'play with' version. So in our plan, when a user adds a new OEM key, I can assigna spare slot in the KeyMaster table, but I'm stymied by the fact that the KeyMaster table is embedded in the EXE using a
#RESOURCE RCDATA KBDATA, "..\Resource File\KeyMaster.txt" statement. I have no way to update it as it only exists in memory via the EXE, and as a file in a development folder.
Maybe I should just ship it with the installation like the HnDIndex.txt file, but I was concerned that it would be tempting for some users to edit and 'break' it. I'd still have to write the file update thing, but that's do-able.
The whole thing is Messy, messy.
George
[UPDATE] Even messier.
User KB customizations are saved in the CFG file as 'overlays' onto the basic KB mapping which is built-in to the EXE file.
Adding a new OEM type key means expanding the basic table, which can't easily be done because it's 'built in'. Even if I externalize the table, it violates allowing different Instances having different KB tables because we're altering the basic table. We'd have to go into Instance unique external tables. Which really implies no need for the user overlay technique. Ick!
Alternatively, it means expanding the capabilities of the user customization to somehow include adding an OEM key, which must go in the basic table - Catch 22.
Other than restructuring the whole KB process, I'm out of ideas.
Maybe throw out user overrides, and just directly modify the Master table (assuming its externalized), and name it with matching Instance ID.
[/UPDATE]
|
|
|
Post by Robert on Dec 5, 2023 12:59:49 GMT -5
Well, you know George, the OEM entries (and others) for the VK codes are fixed by Windows. You CAN'T invent an unknown VK code, that's not how it works. So, there is no need for a user to be able to say "Hey, I have an OEM_8 that you never heard of, let me add it" because Windows already knows what OEM_8 is. The only current deficit is that SPFLite doesn't know what OEM_8 is. But, these are all published values; it's not like they are a secret.
For you to support it, you'd need an unassigned entry for VK = 0xDF and then find a way to let the user put something in it.
Is restructuring things ("a total rewrite") actually necessary? Isn't there something a little less drastic that could be done?
R
|
|
|
Post by George on Dec 5, 2023 13:27:30 GMT -5
Hi, I extracted the VK equates from the API INC files, there's only 193 unique codes, meaning there are roughly 90 codes that don't have a 'home' on the KEYMAP and are thus not modifyable. And most of them are the oddball things like sleep, media controls, browser controls etc., not exactly what most people want to modify. It makes KEYMAP a bit awkward in managing them, but I doubt anyone will have more than a few keys to add.
I'm leaning toward externalizing the table and modifying it directly. To accomodate Instances, it would become, for example KBDDefault.TXT, located in the HomeFolder. Instance Fred would be KBDFred.txt If a user directly edits it and mucks it up, too bad, start over with a standard one by deleting the bad one. Maybe I'll include a HASH so any manual change would be spotted.
So there wouldn't be a Basic table + User modifications, just the single user's version of the Basic one. Simplifies things a lot.
I'm still in think mode.
George
|
|
|
Post by Robert on Dec 5, 2023 13:59:32 GMT -5
I extracted a table from the KbdEdit web site, and got 199 entries, but two are zero and "none" entries, so yours must be pretty close.
When I revamped KeyboardTest, I already had a VK table, but it was missing some stuff, so I just added a second one, and anything I didn't find in the first one I looked up in the second one. Pretty cheesy coding but manually merging two 256 entry tables and trying to come up with one was a pain.
By all means, continue in think mode. This could be screwed up with the greatest of ease if you aren't careful. In my table, there are 33 "OEM" entries, and some of those are "FJ" types, which is a code for "Far East/Japan". Japanese keyboards are very weird, as they have to juggle Latin, Kanji and Kana. Using Japanese is hard. But it's notable that even with FJ entries, there are still less than 256 VK codes. But your table is a good one, because you have handled cases where "enhanced" keys differ based on Num Lock, like VK 0x23 is Keypad 1 if Num Lock is on, but End if it's off. That dual use of the key adds a wrinkle that has to be taken into account.
R
|
|
|
Post by George on Dec 5, 2023 14:14:29 GMT -5
Well, the table I got was from the PB translated version of Microsofts header files, so that makes it pretty official. I eliminated some duplicate names where 2 or more equates all mapped to the same value (SORT UNIQ is handy) I got the same number of OEM entries (33). My file is attached. VK_Equates.inc (6.03 KB) George
|
|
|
Post by Robert on Dec 5, 2023 16:40:56 GMT -5
Here is my comparison of your file and mine. Most are equal, but in some cases I have stuff you don't and vice versa. Some are the same key with different VK names, which evidently are not totally standardized. 0x00 is for a key which is not a data key and is normally ignored. 0xFF is what "KbdEdit" as an unused (unmapped) key internally.
VK_NULL 0x00, "NON-DATA KEY" %VK_LINEFEED = &h0A VK_IME_ON 0x16, "IME ON"
%VK_HANJA = &h19 VK_KANJI 0x19, "IME KANJI MODE"
VK_IME_OFF 0x1A, "IME OFF"
%VK_PGUP = &h21 VK_PRIOR 0x21, "PAGE UP"
%VK_OEM_NEC_EQUAL = &h92 VK_OEM_FJ_JISHO 0x92, "OEM_FJ_JISHO"
VK_ABNT_C1 0xC1, "ABNT C1" VK_ABNT_C2 0xC2, "ABNT C2" VK_NONE 0xFF, "NONE"
|
|
|
Post by George on Dec 6, 2023 9:45:33 GMT -5
Thanks, I added a couple to my version. There were also about 8-9 other aliases, deprecated etc. names in the INC file I got my list from.
George
|
|
|
Post by Robert on Dec 6, 2023 10:01:05 GMT -5
George,
I feel it's important I say something in plain English here: I am not "pushing" this idea; this is not a feature I personally need. I do think the world-wide user base could find it useful, but I want you to know I hear you when you say things like 'nightmare' and 'hack' and all the other words you often throw around. If you genuinely think this is going to break something badly, please don't let me influence you to add something that, honestly speaking, will see only limited use. I mean, I can see a way this could be done by changing KEYMAP into a table-driven UI, and dispense with all the keycap icons. But, that would genuinely be a complete rewrite, and it would be a disservice to all the users that are fine with what we have now. I remember when you first put this up, and I crafted those mouse-button icons for you. That was a very impressive accomplishment at the time, and was SO much better than what you had before.
Don't break a good thing in the name of trying to be nice. Just be careful, ok?
R
|
|
|
Post by George on Dec 6, 2023 11:17:02 GMT -5
Robert: No way KEYMAP would change (much). If I can't come up with a way to do this in a reasonable manner, it just won't go.
It's not like OEM keys that aren't in KEYMAP don't work, it's just they can't be customized. But there's oodles of keys that can, it's not like we're running out.
Biggest problem is migration, and the interaction with Instances. That's a BIG one, a killer. Right now I'd say it's doubtful.
George
|
|