|
Post by Robert on Dec 2, 2023 10:44:12 GMT -5
Hi George,
Well, here goes another one of my whacked ideas. But then, you TOLD me to keep on truckin', so here goes.
I have been thinking about Stefan's keyboard issue. The main problem is that he has a keyboard with a key (under ESC) that has a VK code that does not exist in the US ANSI layout. So, there's no way to keymap it.
Here is my idea. Suppose you had a new button for the KEYMAP GUI, with a label of "Extra". When you click on the Extra button, it brings up a drop-down box where you can define a new key, or select one you've already picked. Once you select one of the "extra" keys, you'd click on a Done button, and you'd be back at the main KEYMAP.
From that point on, there would be a new key icon, with some unique graphic, that indicates you are using that particular "extra" key. Maybe it would be a display of the hex VK code in question. That is TBD stuff.
Then, if you clicked on that icon, it would open up the ability to configure that key, the same way you would configure any other key.
To implement this, besides the new GUI stuff, you'd need to add new keyboard entries in your data structures. Right now, I believe the array is from 0 to 107. You would have to decide how many more to add. 8? 16? 32? Not too many, but not too stingy, either. Then, when you do physical I/O from the keyboard, you would have a new, longer list of valid keys to interpret.
I don't want to over-specify this, but I believe our non-North-American users might be able to put this to good use.
R
|
|
|
Post by George on Dec 2, 2023 11:59:40 GMT -5
Yes, it would take an expansion of the table, a very messy proposition. We did it once when we added the 3 mouse keys to the setup - it was painful. I suppose we could squish the mouse keys to the left and add the EXTRA key in the upper right corner, that would be the least disruptive. The KEYMAP dialog is the busiest and most complicated. This would have to be carefully done along with possibly changes to the keyboard trap and raw handling routines.
Needs to be justified by some user comments.
George
|
|
|
Post by Robert on Dec 2, 2023 13:54:44 GMT -5
I see the task as a two-part thing. The first is the mechanics of changing the keymap GUI, which I know from your many comments of yesteryear, how it's a grand pain. The second is the issue of simply supporting more entries into wherever you store the keymap (in SQLite somewhere, I assume).
Just to be sure I explained it right, I see the GUI as needed two new buttons. One is used to select which extra key you want, and the other is using that key to assign things to it. As with everything, picking the right names is important.
Right now, if you're in KEYMAP, and you click on the Bksp key, you see a caption, "Current Key: BKSP". You see the 8 possible shift states, and the "Bksp" legend on the regular keyboard diagram gets obscured.
I propose a new "pseudo" key in the keyboard diagram. I would put it just above the ↑ up arrow and under the End key, where there is a gap present where no key exists now. That new pseudo key would be called "Extra". Whenever you click on this pseudo key, it means you want to configure "the" extra key - WHATEVER THAT IS AT THE MOMENT.
But, what IS the extra key at the moment? You can click on the Extra key and it would show you. What kind of name would an extra key have, anyway? That is TBD, but possibilities include the "VK" code like hex DF, or we could look up Microsoft's terminology for a given VK code. For instance, on Stefan's keyboard, a VK of hex DF is called VM_OEM_8. If there were to be any OTHER kind of name, this new feature we make would have to allow for some kind of user-supplied name. Yeah, more work, unappealing, I know.
Now, suppose there IS no Extra key(s) defined yet? There would need to be a second new button, perhaps near where Cancel and Done are, with a label like "Setup Extra".
Setup Extra would bring up a new, never-before-seen GUI. It would allow a user to add a VK code to the list of "known key codes", and perhaps allow them to label it. It would also allow the user to select from an existing known key code and enable it as THE "extra" key. Why this way? Because, to minimize the impact to the existing KEYMAP gui, we would only allow ONE extra key to be keymapped at any given time. If a user had more keys to deal with, they would have to go to Setup Extra again, and pick another one.
I believe this pretty much explains the concept as well as I have thought it through.
Suppose this feature existed now, and Stefan wanted to use it to support his keyboard. What would he do?
1. The "Extra" key in the (revised) KEYMAP would be grayed out, because this is the first time the feature was being used and nothing was enabled yet. He would click on Setup Extra.
2. The new SETUP EXTRA KEY Gui would appear. There would be a dropdown that would show an available list of VK values. A user could only ask for KNOWN VK CODES, not arbitrary values, AND only ones that were NOT already in the standard US ANSI layout.
3. There would be some 'action' buttons, to select, add or delete the selected key from the list.
4. The last key added or selected would become THE active Extra key. If the user just deleted an Extra key from use, and didn't add or select something else, the Extra key would be inactive and the main GUI would show it as grayed out.
5. Stefan would then click on Done on that GUI, and would return to the main KEYMAP. Then, clicking on the "Extra" button, he could proceed to configure any of the shift-levels for that key.
Does this explanation help any?
R
|
|
|
Post by George on Dec 2, 2023 14:35:06 GMT -5
Robert: I was thinking along these lines.
There would be 8 allowable "Extra" keys. Lets call them X1 thru X8.
One new key would be displayed in the upper right corner as I previously described. By default it will display X? or just ? or ...
When clicked on in the X? state it will show a dropdown list with VK-Code and Username columns. Initial default for all these is null/blanks/whatever. User can then fill in the 'whatevers' for the key(s) desired and select one row. The dropdown will close and the appropriate Xn icon will appear on the key.
Selecting the key when it displays X1 thru X8 will perform the normal KEYMAP activities.
This means only 1 new key and fairly basic operation.
George
|
|
|
Post by Robert on Dec 2, 2023 15:23:57 GMT -5
I think our two concepts are very similar. You seem to have a good grasp on the idea. The hard part of course is shoving all that stuff into existing code.
I agree that "1 new key", at least as just one new key added to the KEYMAP gui, should be enough. So, you could see X1 on the GUI, but not X2 through X8, at any give time. If you wanted to work on X2, you have to specifically select it, and then that ends your ability to work on X1, until you went in and re-selected X1.
Right?
|
|
|
Post by George on Dec 2, 2023 15:43:02 GMT -5
Yes, problem is when the key shows something other than X? you don't get the pulldown, you modify that key.
I think the pulldown will have to be via a right-click. But that also means that the key could be populated right off with the 1st entry. And if you only have 1 entry, well that's perfect.
George
|
|
|
Post by Robert on Dec 2, 2023 16:27:27 GMT -5
So, initially, KEYMAP would show a new icon like "X?" which means the Extra key was not yet configured. To decide what exactly X? meant, you would RIGHT-click on "X?", which brings up the Setup Extra GUI. You select what you need (like, say that X1 means VK_OEM_8), then leave the Setup Extra GUI. If you THEN want to actually define the various shift levels for X1, you would LEFT click on the icon that NOW shows X1.
You would have to "know" what X1 meant, or else your Setup Extra GUI might have to allow for a user-written "note" (?) or label of some kind. (I think). That user-provided label would appear somewhere on the KEYMAP GUI.
George, I believe you are going in the right direction on this. Will still be a bunch of work, but conceptually, what you are saying makes sense. It seems like it would functionally work correctly.
Only point we seem to differ on is where to actually put this "soft key icon" like X? / X1. I think you should use the space above the arrow keys and below the Delete/End/Page-Down area, since it's free and has a lot of room.
R
|
|
|
Post by Robert on Dec 2, 2023 18:25:37 GMT -5
OK, so far so good, but there's a little detail that needs to be handled. So, say you are Stefan and you are trying to fix your keyboard, because the key under ESC is sending VK_OEM_8 and you don't know what to do with it. So, you go into the brand-new fixed-up KEYMAP and right-click on the "X?" "extra" key, which brings up the Setup Extra Key GUI.
Now what? What does Stefan enter to tell the new GUI which key he means? Yes, he could have run KeyboardTest.exe and seen that the VK is DF and the Scan Code is whatever it is. So, he's supposed to write down on a piece of paper what these magic numbers are and do something with them? Um, not so easy to do.
I believe the correct way to handle this is that the Setup Extra Key GUI would have a dialog where it says, "Type the non-standard key you wish to access" or something like that. They type the key, and you capture the VK code coming in. You verify that they are not trying to remap a normal key like W. Then, that key gets associated with X1 through X8, whatever the user picks to symbolically call it.
Does this sound right?
R
|
|
|
Post by Robert on Dec 2, 2023 23:52:43 GMT -5
I am thinking that if this idea moves forward, we might need to upgrade the KeyboardTest program. Right now, it shows the VK hex code, but not its name. So, we would see VK = X'DF' but not VK_OEM_8.
That part wouldn't be too bad, but maybe other information could be useful too?
Any ideas?
R
Quick check: I found an old version of this code, I wrote it 12 years ago. Sheesh. I am so old.
|
|
|
Post by Jo on Dec 3, 2023 7:47:29 GMT -5
My Logitech-K200 keyboard has 8 extra keys above the F1-F12 keys. They are for video-start/pause, speaker on/off, volume-+, internet, mail, sleep, calculator. Could we then remap those keys as "Extra Key" ?? Enter any key, or press ESC twice to cancel VK SC HEX DEC C *ALT *CTRL CAPS NUM SCR *SHIFT ENH KEYNAME == == === === = ==== ===== ==== === === ====== === ======= B3 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key AD 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key AE 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key AF 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key AC 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key B4 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key *) *) the sleep-key was not seen by KeyboardTest
B7 00 00 000 ---- ----- ---- --- --- ------ ENH Unknown key
nice idea ! Jo
|
|
|
Post by Robert on Dec 3, 2023 9:24:18 GMT -5
Hi Jo,
I am not certain, but I suspect the answer is probably not. The reason is that SPFLite is monitoring keys for "key messages". When you request Windows to run the calculator, it's not a "key" like F7 or ESC. Pressing it sends a system message to Windows, which then launches the calculator program. SPFLite doesn't see it, even to apply the (PassThru) action. It isn't a "pass-through", it's a "bypass".
You notice in the display above, the scan code (SC) and data values (hex/dec) are zero. When a program gets a zero like this, they are normally supposed to ignore the key press.
Likewise, the Sleep key (pause) is captured very early in Windows' physical I/O from the keyboard. It has to, otherwise a busy program might prevent it from being detected; it has to have very high priority. So, it is "grabbed" before the keyboard device driver even sees it.
Certainly, if this new feature gets implemented, it would be well worth the attempt to try and do it and see what happens. But, don't get your hopes up that you could now have 8 new functions keys. Don't think that will work, sorry.
R
P.S. I have a logitech keyboard with the same media keys. So far I haven't been able to remap them using any software I have.
|
|
|
Post by George on Dec 3, 2023 11:35:22 GMT -5
Robert: Having the popup do a keyboard capture is way more than I want to do. I fully expect the user who wants to do this to run Keytest and 'remember' the key code, I don't think that's too onerous a task.
If this goes ahead (and there seems to be interest in it) it's going to be a very messy change, mainly in the migration code. Adding a few entries is not bad, but migrating will be tough, let alone how to handle CFGMaint and old export files. There's a lot of code and structure dependent on the current sizing.
George
|
|
|
Post by Robert on Dec 3, 2023 11:38:24 GMT -5
George, I wanted to ask if you have the most current version of KeyboardTest.cpp. I have a very old version, but I looked in your source distribution, and you only show the .exe file.
I believe if users are going to be dependent on KeyboardTest.exe, I need to make the output a little more understandable, so I need to revise the C++ code.
R
|
|
|
Post by George on Dec 3, 2023 12:27:16 GMT -5
Robert: Never noticed that it has gone AWOL. I'll go back through the archives and dredge it out, it has to be there somewhere.
George
[UPDATE] Well, if you have a source, then it's the only one. I went back to the V5.0 release, when the new KB support was released, and the EXE is there, but not the .cpp file. I scanned various intermediate releases and it's not there either. But i do remember it being in there.
[/UPDATE]
|
|
|
Post by Robert on Dec 3, 2023 13:26:09 GMT -5
I do have a couple different versions laying around. I think I will take the most likely version and make a copy as KeyboardTest2 just to be safe.
I must have just compiled it and gave you the EXE because you didn't have a C compiler at the time.
R
|
|