Alt+Number Combinations

[Donald Love]

I have tried converting a program I wrote for earlier Windows versions to work in a DOS window for Windows XP that use the Alt+Number keys (Alt+1, Alt+2, etc.) to shift between one subject and other subjects. With Windows XP however, the keystroke combination is apparently getting intercepted by Windows and it never gets to my program. Has anyone experienced this, or know how to get around it?

[Scott Slater]

Is there an option in the short-cut for this? (considering that you have created a shortcut in Windows that points to your DOS program)

[Donald Love]

Sample program

Here is a program to illustrate the problem

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
LOCAL A$
rewt:
A$=WAITKEY$
IF LEN(A$)=2 THEN
PRINT "2-CHAR KEYSTROKE DETECTED ";ASC(LEFT$(A$,1)),ASC(RIGHT$(A$,1))
GOTO rewt
ELSE
PRINT "1-CHAR KEYSTROKE: ";ASC(A$)
IF A$<> CHR$(27) THEN GOTO REWT
END IF
END FUNCTION

This is compiled with PB/CC 4.03 (Am I in the right forum?). When you run it, you hit a key (or a key combination) and it tells you the ascii value of the keystoke or, if it is an extended keycode, it identifies that and identifies the combination value. Alt+1 through Alt+0 should show up as an extended code with the second value being 120 through 129 but it shows up as just as just the ASCI values for 0 through 9 (48 through 57) and not as an extended code.

You type in an 'Escape' key to exit the program.

I use the numbers for one type of user response and the Alt+number combinations as a different request by the user. I could probably switch to the Function Keys, but I'm trying to figure out why the system isn't working as expected.

[Donald Love]

I created a shortcut but didn't find any options that seemed to address this. I did try changing the "Compatibility" for earlier versions of windows, but it did not change the way the program responds.

[Cliff Nichols]

Just a sidestep of "When posting, try to post code as code"
1.) Either hilight your code and hit the code button or
2.) put [c o d e ] <Insert Code> [ / c o d e ] (take out the spaces) around your code. that way your code appears as

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
   LOCAL A$
rewt:
   A$=WAITKEY$
   IF LEN(A$)=2 THEN
       PRINT "2-CHAR KEYSTROKE DETECTED ";ASC(LEFT$(A$,1)),ASC(RIGHT$(A$,1))
       GOTO rewt
   ELSE
       PRINT "1-CHAR KEYSTROKE: ";ASC(A$)
       IF A$<> CHR$(27) THEN GOTO REWT
   END IF
END FUNCTION

so that others can read it

[Donald Love]

This was my first time on a Support Forum - Didn't know you could do that. I haven't found the code button, but I'll keep looking for it.

[Scott Slater]

Donald,

I have Vista-64 here so I can't run DOS programs directly under it, but I do recall that there were some options when you right-click on a shortcut and go to the properties for the shortcut for Alt mapping. If not, I suppose you could always change the keys to CTL-1 etc.. I know regular ALT keys (ALT-letter) always worked in a DOS window under XP, but I never tried ALT-number.

[Scott Slater]

This is compiled with PB/CC 4.03 (Am I in the right forum?). When you run it, you hit a key (or a key combination) and it tells you the ascii value of the keystoke or, if it is an extended keycode, it identifies that and identifies the combination value. Alt+1 through Alt+0 should show up as an extended code with the second value being 120 through 129 but it shows up as just as just the ASCI values for 0 through 9 (48 through 57) and not as an extended code.

Oh, that's a PBCC ap, not DOS... That's why you won't see any options for that. You need to look at INKEY$ instead of WAITKEY$

[Scott Slater]

I meant INSHIFT, not INKEY$, but here's an example using INKEY$ & INSHIFT

#Compile Exe
#Dim All
 
Function PBMain () As Long
 
    Local KeyData As String
    
    Do
       Do
          Sleep 0
          KeyData = InKey$
       Loop While KeyData = ""
       Select Case KeyData
          Case Chr$(27) ' Esc
             Exit Loop
          Case Chr$(49) ' Alt-1
             If (InShift And 3) Then
                ? "Alt-1 pressed."
             End If
          Case Chr$(50) ' Alt-2
             If (InShift And 3) Then
               ? "Alt-2 pressed."
             End If
       End Select
    Loop
 
End Function

[Mike Doty]

[FONT=Courier New]Key  DOS CTRL   DOS ALT       PBCC CTRL   PBCC ALT[/FONT]
[FONT=Courier New]---  --------   ----------    ---------   --------[/FONT]
[FONT=Courier New]1    0 + 117    0-255         0 + 79      0 + 79[/FONT]
[FONT=Courier New]2    0 + 145    On release    0 + 80      0 + 80[/FONT]
[FONT=Courier New]3    0 + 118                  0 + 81      0 + 81[/FONT]
[FONT=Courier New]4    0 + 115                  0 + 75      0 + 75[/FONT]
[FONT=Courier New]5    0 + 143                  0 + 76      0 + 76[/FONT]
[FONT=Courier New]6    0 + 116                  0 + 77      0 + 77[/FONT]
[FONT=Courier New]7    0 + 119                  0 + 71      0 + 71[/FONT]
[FONT=Courier New]8    0 + 141                  0 + 72      0 + 72[/FONT]
[FONT=Courier New]9    0 + 132                  0 + 73      0 + 73[/FONT]

[Donald Love]

Thanks, Scott, I'll use the INSHIFT logic. It just seems strange that some of the 2-character keystrokes work (e.g., Alt+Alphabetic Key) but not all.

Mike, looks like you get similar results as I do with PBCC but your results are for the Numeric Keypad with NumLock 'off'.

Thanks for the help!

[Paul G. Penn]

Using the ROM BIOS to read the keyboard

If you're working in MS-DOS (or Windows in a DOS box), I can probably understand why you'd want to use INSTAT/INKEY$ to read the keyboard. But there's a problem when using INKEY$ within Windows...Some key combinations are pre-set to be used by Windows (Alt-F4 to close the top window, for instance) so if your program needed one of these, you're out of luck. Other Windows key-combinations are normally trapped, but can be passed by clicking on the program's Properties tab, then clicking on the Misc tab. The selectable key combinations are at the bottom of the page with check boxes. If a box for a combo is clear, Windows won't trap the keystroke, passing it on to the program. Now, it would seem to me that if you wanted to read the keyboard with guaranteed results, why not use the ROM BIOS 0x16 keyboard services built right into MS-DOS and all versions of Windows? Using the ROM BIOS would return the ASCII character and scan code of almost every key on the keyboard, including Ctrl- and Alt- key combinations. Here's what I use:

$COMPILE UNIT
 
UNION CharacterOrByteUnion
   ValueAsCharacter AS STRING * 1
   ValueAsByte      AS BYTE
END UNION
 
UNION SignedOrUnsignedUnion
   ValueAsSigned   AS INTEGER
   ValueAsUnsigned AS WORD
END UNION
 
TYPE KeyboardDescriptorType
   ASCIICharacter AS CharacterOrByteUnion
   ScanCode       AS BYTE
END TYPE
 
TYPE HiOrLoType
   LoByte AS BYTE
   HiByte AS BYTE
END TYPE
 
UNION RegisterDescriptorUnion
   RegisterAsWord AS WORD
   SplitRegister  AS HiOrLoType
END UNION
 
SUB ReadKeyboardBIOS(KeyboardDescriptor AS KeyboardDescriptorType) PUBLIC
 
DIM AX AS LOCAL RegisterDescriptorUnion
 
AX.SplitRegister.HiByte = 16? ' 0x10 = Read Extended Keyboard
AX.SplitRegister.LoByte =  0?
 
REG 1??, AX.RegisterAsWord
 
CALL INTERRUPT &H16
 
AX.RegisterAsWord = REG(1??)
 
KeyboardDescriptor.ASCIICharacter.ValueAsByte = AX.SplitRegister.LoByte
KeyboardDescriptor.ScanCode                   = AX.SplitRegister.HiByte
 
END SUB

So to read the keyboard, I just do:

 
ReadKeyboardBIOS KeystrokeData ' assuming KeystrokeData was DIM'd with the 
                               ' TYPE KeyboardDescriptorType from the unit
 
SELECT CASE KeystrokeData.ScanCode
    CASE 119 ' Alt-0
       <statements>
    CASE 120 ' Alt-1
       <statements>
.
.
.
END SELECT

This won't get all the combinations, but it's more efficient than using INKEY$ for reading the keyboard, especially when you want the scan codes for the regular keys (which INKEY$ doesn't return).