> the user told you to type ASCII 13. why don't you 'type' 0x13 using > INT16, AH=05h? use scancode 0x02 and send complains to me?
I'm not actually "complaining" about MKEYB since KEYB is available and does things "correctly" -- so there's no need for me to use MKEYB. In fact, as a user, I live in the US and there's no need for me to even use FD-KEYB except for testing. Why would I assume I should use Scancode 02h and not some other Scancode? That's the point -- in at least some cases, the user would also need to tell me which Scancode to use, but they can also JUST tell me the Scancode since I don't even care about the ASCII code. Some programs treat Ctrl-M very different than Enter while others don't know the difference. With SCANCODE, the user can tell me to "type" Enter or Ctrl-M and it does EXACTLY that. Again, what I'm trying to do is make it easier for the user, not necessarily easier for me. You can also provide the Scancodes directly to SCANCODE if you want (the very first versions of SCANCODE from a long time ago required that). The ASCII codes are there to make it easier for the USER to use the program. > in addition, many keyboard handlers were able to produce 'keys' by > holding down ALT and hitting 3 decimal keys to produce a 'ASCII' > code. I think they all do that (or at least should do that). SCANCODE will "type" the keys that way also when it's required (like when it doesn't think there's another keystroke combination on the keyboard that will work). You can also tell it specifically to type as an Alt-NumPad combination. SCANCODE is actually far more flexible in what you can do with it than the other keyboard-stuffing programs. > the best solution that "ÄÖÜà" survives the the back and forth > translation is to use INT 16, AH= 5 No, not unless you (in at least some cases) also provide the appropriate Scancodes to go along with the ASCII codes. I also know some programs will accept almost any Scancode (it doesn't even need to be "correct"). > as there are no standards about 'keyboard translation tables', you > would have to carry all this information in your SCANCODE tsr. There are no standards about how the translation tables are laid out, but there are absolutely standards about what each keyboard layout is supposed to accomplish, which is what matters. SCANCODE doesn't actually need to keep the information in the TSR itself. The Scancodes are stored in a buffer, and they are "typed" later as they are needed. After all the keys have been "typed", SCANCODE removes itself from memory when it detects that it is safe to do so. SCANCODE can "type" the keys milliseconds or months later than when the TSR is installed in memory. The TSR monitors things like screen contents and time delays and even other keystrokes so the keys are "typed" at the correct time. So, the installation part of SCANCODE needs to know the ASCII-to-Translation tables, but the TSR itself does not. In addition, this means that the state/environment of the computer (including things like the current keyboard layout or code page) may be different when the keys are "typed" than it is when the TSR is installed into memory, and the directions the user provides to SCANCODE as to what Scancodes to type when need to take all that into account. SCANCODE can do anything a keyboard-stuffing program can do (at least any that I've seen), but it doesn't work the other way. SCANCODE can also be difficult to use, and allows you to automate almost any process that normally requires you to sit in front of a keyboard and "babysit". The way SCANCODE does things is not the WRONG way to do them -- it is certainly different than what you're used to, but is also far more powerful. Allowing the user to enter ASCII codes as input parameters just make it easier for the USER. > I still think that > > SCANCODE some options 'a' > > should send 'a' to my program, whatever the codepage is. It will, but it does it by "typing" the appropriate keystrokes from the keyboard (whatever those are) instead of just sending an "a" with an arbitrary Scancode attached. For example, if the keyboard is currently in Foreign mode where there is no "a", it can temporarily switch the keyboard into English mode, type the "a", and switch back to Foreign mode again, or it can do the Alt-NumPad thing, or even something else. It simulates exactly what you would do if you were sitting at the keyboard, not what happens after the computer is done "processing" and "translating" what you would do if you were sitting at the keyboard. Those are very different things. In many cases it doesn't matter which way you do it, but in other cases it does. And when it does matter, SCANCODE is the only program that will work. > good luck with that. > I don't think that is solvable in 8-bit land. and xxDOS is very much > 8-bit land. It's already done. SCANCODE has been doing it for years. It is not 100% by a long shot, but is VERY effective. _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
