Announcement

Collapse
No announcement yet.

F12 problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • F12 problem

    Using INKEY to read keystrokes, if I hit F12, the contents of the two byte key stroke are 0,134. If I UCASE that, it gives 0,143. None of the other F-Keys act that way, they all return the same number... I was under the impression that a UCASE on any two byte key stroke wouldn't change it... Is UCASE supposed to change the value for F12 like that?

    btw, this is in PB3.5/DOS running under Windows 98

    Here's the program I used to test it...

    Code:
    WHILE zz$ <> CHR$(27)
      zz$=INKEY$
    
      IF LEN(zz$) THEN
        IF LEN(zz$) > 1 THEN
          ? TRIM$(STR$(ASC(RIGHT$(zz$,1))))+"  "+ _
          TRIM$(STR$(ASC(RIGHT$(UCASE$(zz$),1))))+"  "+ _
          TRIM$(STR$(ASC(RIGHT$(LCASE$(zz$),1))))
        ELSE
          ? zz$+"  "+UCASE$(zz$)+"  "+LCASE$(zz$)
        END IF
      END IF
    WEND
    Thanks,
    Jason

    [This message has been edited by Jason McCarver (edited February 08, 2000).]

  • #2
    Another interesting find...the LCASE of F7 will change it from 0,65 to 0,97, but the UCASE dosen't change it....
    LCASE of F8 changes 0,66 to 0,98
    LCASE of F9 changes 0,67 to 0,99
    LCASE of F10 changes 0,68 to 0,100

    Strange...

    ------------------


    [This message has been edited by Jason McCarver (edited February 08, 2000).]

    Comment


    • #3
      Jason --

      Not so strange...

      As you know, the "extended keys" return two-character-long strings that start with CHR$(0). For example, F8 returns 0,66 which is the same as CHR$(0) + "B". If you LCASE that string you get CHR$(0) + "b" or 0,98.

      The LCASE and UCASE functions have no idea where your strings come from (INKEY$ or whatever), they just convert the case of certain characters and ignore others. If an extended key's INKEY$ is not affected by LCASE or UCASE, that just means that 1) it does not contain any characters that are affected by those functions, or 2) the string is already in the requested case. For example, F8 will not be affected by UCASE because it already contains an uppercase B. But it will be affected by LCASE.

      HTH.

      -- Eric

      ------------------
      Perfect Sync: Perfect Sync Development Tools
      Email: mailto:[email protected][email protected]</A>



      [This message has been edited by Eric Pearson (edited February 08, 2000).]
      "Not my circus, not my monkeys."

      Comment


      • #4
        duh You are correct...that makes sense... Of course .. UCASE and LCASE don't care where the string came from...I don't know what I was thinking

        Thanks for pointing out what should have been obvious ..

        Jason

        ------------------

        Comment

        Working...
        X