|
|
Post by Robert on Dec 6, 2023 20:32:49 GMT -5
George,
Let me see if I got this straight. Because of the way you handle migration and Instances, anything that changes or impacts those features becomes, in effect, an insurmountable barrier to updating SPFLite in any meaningful, structural way.
Do you remember the old, old mainframe days when people used DA files with absolute disk addresses recorded as data? When they did that, you couldn't upgrade to new DASD types, because the CHR addressing would no longer be compatible. That was one incentive for developing VSAM. IBM had big customers that needed to directly point to disk records, but the old DCB RECFM=DA locked them in to their old device types and device geometries. IBM was absolutely forced to make VSAM, or else they and their customers were hosed.
Forgive me, George, but I believe you have hosed yourself here. You have turned SPFLite into almost an unmodifiable monolith. This is not good.
My advice would be to extricate yourself and your code from this predicament ASAP. That is the most important change you possibly could make to SPFLite at this time - far, FAR more important than making an extensible KEYMAP or anything else (period).
I'd be happy to chat this one up with you, but you need to first come to terms with what I just said. Let me know when it sinks in. Pour yourself a glass of wine. You'll need it.
R
|
|
|
|
Post by George on Dec 7, 2023 9:56:28 GMT -5
Robert: I fully realize where SPFLite sits, and how hard it is to do things, after all, I'm the one looking at the code almost every day. Over the years we (ME) have taken the expedient route to adding stuff. If we had been prescient enough to see where things would lead maybe we could have done things differently, but that bridge is behind us.
If you have some splendiferous method for re-organizing all this stuff, I'll listen, but if it means re-writing massive parts of the program, you know my answer. All this stuff with Options, Instances, Profiles etc. is so intertwined and embedded throughout the code I doubt anything can be done without starting over.
George
|
|
|
|
Post by George on Dec 8, 2023 11:35:08 GMT -5
Robert: Expanding the KB area is tricky, yes, but saying I've hosed myself seems a bit extreme. That KB code was written over 12 years ago, has never had any significant changes and has stood the test of time quite well. I don't look back and say "Boy! We really should have thought that out better".
The question here is really "Is there sufficient interest from users to tackle this?"
So Users: How important is it to be able to, in KEYMAP, access the extra OEM keys on non-US keyboards?
Remember, the keys are functional as far as generating what they show on the keycaps, you just can't modify them in KEYMAP.
George
|
|
|
|
Post by Robert on Dec 8, 2023 13:12:57 GMT -5
George, my apologies for the apparent slight. What I was referring to is not what you did 12 years ago. I still like what you did, and I remember what the keyboard support was like before, so I really have no complaints about that at all.
The issue I was referring to it what Instances and migration have done. Once you create something that supports that, like multiple-instance keymaps, it seems like it is locking you in. I know have I seen you refer more than once to that problem.
Based on my keyboard knowledge, I believe that even though there are many VK codes that SPFLite doesn't support, the number that an actual user might need to add is going to be small. You might get away with just one or two "flexible" keys, and maybe 8 at the most. And, those are only needed if an SPFLite-KEYMAP-based remapping is needed. When you use a keyboard with its native keyboard driver, you can always use all of the keys as-is, as if they were all "pass-though", because SPFLite as a Windows application just passes along any VK key it doesn't recognize. Bottom line, there just won't be a lot of "expansion" needed. I suspect the majority of non-US keyboards might only need one extra one. The rest they can leave as is, as you noted in your last sentence above.
R
|
|
|
|
Post by George on Dec 8, 2023 15:01:11 GMT -5
Robert: I've been exploring code. I think I can add 3 OEM keys above the 4 arrow keys. And I've looked at the way the customization is saved. Pretty sure this can be accomplished without extreme changes. Still more research to do.
George
|
|
|
|
Post by Robert on Dec 8, 2023 15:28:08 GMT -5
I believe 3 OEM keys should be enough, provided that we can put any desired unused VK code we want.
For example, in the UK, French and German keyboards, they each only have one extra vk code.
R
|
|
|
|
Post by Stefan on Dec 9, 2023 5:12:02 GMT -5
Guys,
I'm sorry to have sparked off this issue with my original question - Why can I not map the key below ESC? Robert has already explained that, so I consider the matter closed.
To formally answer Robert's earlier question...
This user is happy with the constraint, given the effort required to add a new VK code. Others may feel more strongly, but I can live with what we already have.
But it looks like it is has turned into an interesting technical challenge which has gripped you both. I guess we've all been there in the past. ;-)
|
|
|
|
Post by Robert on Dec 9, 2023 9:21:52 GMT -5
Stefan, after further investigation, I found that the key next to Enter, which has #~ on it, can produce / and| when used with AltGr and AltGr+Shift. If you were able to live with that, the key that actually shows /| on it has OEM_5 which means it's the same as the US English \| key. If you needed to put something there, you could, even on the normal and shift states, without losing the ability to type \| just knowing that you would then need AltGr for them.
Does that help?
R
|
|
|
|
Post by Stefan on Dec 9, 2023 10:57:46 GMT -5
Robert,
I'm probably just being stupid, but I don't quite understand what you're telling me. I think mapping new primitives to this/these keys isn't possible.
As you said, the key left of [<--'] is labelled [#~] (normal and Shift) and I confirm it generates \ and | if pressed with [AltGR] and [Shift-AltGR].
Keyboardtest returns the following for the [#~] key:
VK SC HEX DEC C *ALT *CTRL CAPS NUM SCR *SHIFT ENH KEYNAME
== == === === = ==== ===== ==== === === ====== === =======
DE 2B 23 035 # ---- ----- ---- --- --- ------ --- '
DE 2B 7E 126 ~ ---- ----- ---- --- --- LSHIFT --- '
DE 2B 5C 092 \ RALT LCTRL ---- --- --- ------ --- '
DE 2B 7C 124 | RALT LCTRL ---- --- --- RSHIFT --- '
Using Keymap I can assign values to this key (DE) in all the categories, but it only ever produces the assigned characters plus \ and |.
My keyboard also has an extra key between [Left-Shift] and [Z] which is labelled [\|] and produces those characters (normal and Shift).
Keyboardtest returns the following for this extra key:
VK SC HEX DEC C *ALT *CTRL CAPS NUM SCR *SHIFT ENH KEYNAME
== == === === = ==== ===== ==== === === ====== === =======
DC 56 5C 092 \ ---- ----- ---- --- --- ------ --- \
DC 56 7C 124 | ---- ----- ---- --- --- LSHIFT --- \
DC 56 00 000 RALT LCTRL ---- --- --- ------ --- \
DC 56 00 000 RALT LCTRL ---- --- --- RSHIFT --- \
I also note the Keyname column for (DE) shows ' which appears to be a separate key, labelled ['@] (normal & Shift) and placed immediately to the left of key labelled [#~] on my keyboard.
I can specify new primitives for this key, but none produce data other than ' and @
Keyboardtest returns the following for the ['@] key:
VK SC HEX DEC C *ALT *CTRL CAPS NUM SCR *SHIFT ENH KEYNAME
== == === === = ==== ===== ==== === === ====== === =======
C0 28 27 039 ' ---- ----- ---- --- --- ------ --- `
C0 28 40 064 @ ---- ----- ---- --- --- LSHIFT --- `
C0 28 00 000 RALT LCTRL ---- --- --- ------ --- `
C0 28 00 000 RALT LCTRL ---- --- --- LSHIFT --- `
The ['@] key generates a VK value of C0 and it's Keyname is the reverse quote `
So we've come full circle, because the reverse quote is the 'normal' symbol generated by the key below ESC, which is where we started.
Not to worry, it is what it is.
|
|
|
|
Post by Robert on Dec 9, 2023 11:59:43 GMT -5
I am confused. You said,
"Using Keymap I can assign values to this key (DE) in all the categories, but it only ever produces the assigned characters plus \ and |." But, isn't that what you wanted? What's the problem here? It sounds like it's doing exactly what you asked it to do, but for some reason, you're unhappy. Why?
Note that the combination of RALT + LCTRL is what happens when you use AltGr. Now, maybe KEYMAP isn't recognizing this modifier state? I'm not sure. I thought it would treat it merely as ALT+CTRL and ignore the left/ride 'sides' of them.
VK 0xDE = VK_OEM_7 which on the US keyboard is the key with ' and " on it. The UK keyboard uses that physical key for the '@ because they put the " quote on key 2. Did you use the ' " key to do your KEYMAP with?
Note also that for your '@ key, AltGr doesn't produce anything because the device driver has none assigned.
I would have to ask George about this. Because KEYMAP is written with the assumption that the device is a US ANSI keyboard, it may not be possible to KEYMAP any shift state for AltGr because it's not getting recognized.
I am going to run some experiments ... will update this shortly.
R
|
|
|
|
Post by George on Dec 9, 2023 12:12:00 GMT -5
I'm curious as to why DC DE and C0 don't work properly. Those values are %VK_OEM_5, %VK_OEM_7 and %VK_OEM_3. They are all 'standard' keys on the US 104 key keyboard and defined in the normal KB tables.
This is why I'm extremely leery of fiddling with the KB handling. It took a lot of fiddling and tweaking many years ago to get it to todays state.
I think this whole area is best left alone. I don't even have a non-US KB to test with. There's nowhere near enough payback to justify the effort of changing and testing all this.
George
|
|
|
|
Post by Robert on Dec 9, 2023 12:14:01 GMT -5
OK, did the experiment. When you hold AltGr, SPFLite does in fact see right Alt plus left Ctrl, but it is not looking at the right/left sidedness of it, but just treats them as ALT+CTRL. I was able to keymap your #~ key by using the KEYMAP keycap shown as '" and everything worked, whether via AltGr or via ALT+CTRL.
I believe you are just using the wrong KEYMAP entries. It should be possible to map the keys and get them to work.
R
|
|
|
|
Post by Robert on Dec 9, 2023 12:17:25 GMT -5
Stefan, I believe part of the problem is that you don't have sufficient documentation to understand the particulars, and you are dealing with trying to translate the UK keyboard to the KEYMAP layout, and you're comparing apples to oranges.
So, I would ask you to explain *exactly* what you want *which* of your UK keys to do. Don't leave out any details. Then, I will use my UK keyboard to test it. I am sure we can get this to work.
R
|
|
|
|
Post by Stefan on Dec 9, 2023 17:18:58 GMT -5
Robert,
I dont know what you're trying to tell me with your "after further consideration...." post about 8hrs ago.
I thought you were showing me another possible way to add primitives to the Keymap. My response described why I thought it could not be done, given the keyboard I have.
I am not trying to achieve something new following your explanation of why I can’t remap the key below ESC. I thought you were offering a possible solution using the #~ key but I couldn't make it work.
Let's drop this. It is what it is. This part of the code seems both complex and fragile and unless other users make a good case for changes to KEYMAP, I see no reason to pursue further enhancements.
|
|
|
|
Post by Robert on Dec 9, 2023 17:50:06 GMT -5
Stefan, I could use my keyboard tools to make you a custom device driver. That's why I want to know exactly what assignments you want to make to which keys.
I need you to trust me on this. Don't give up.
R
|
|
