waitkey( )

Blitz3D Forums/Blitz3D Beginners Area/waitkey( )

Agamer

(Posted 2003) [#1]

Ok as wait key gives you like 16 for the w
I want to convert it to give me a the letter so i came up with this

Graphics 800,600,16

If KeyDown(16)
text 0,0,"W"
EndIf 

Delay 5000

Foppy

(Posted 2003) [#2]

I looked at the GetKey() help and found the following code. GetKey() checks if the user presses a key and returns the ASCII value. This is printed to the screen. Then I added a line which converts the ASCII code to the corresponding character, using the Chr() function, and prints that to the screen as well.

; GetKey Example

Print "Please press any ASCII key..."

While Not value
   value = GetKey()
Wend 

Print "You pressed key with an ASCII value of:" + value

Print "This corresponds to the following character: " + Chr(value)

WaitKey

Instead of the While...Wend loop with GetKey() you could also use a single call to WaitKey() I guess, as that command will wait until a key is pressed. It also returns the ASCII code.

Print "Please press any ASCII key..."

value = WaitKey()

Print "You pressed key with an ASCII value of:" + value

Print "This corresponds to the following character: " + Chr(value)

WaitKey

Oldefoxx

(Posted 2003) [#3]

You can also check for KeyDown() and KeyHit() if you know what keystroke you expect, based on the Scankey codes. This approach makes it easy to watch for keys to occur in any order, or detect if they are being held down. A waitkey() means that you are stopped from further action until some key is pressed, which is fine if that is what you want, but it also means that nothing in your program is going to be performed until some key gets pressed, whether it is the one you expect or not. It's most common use of Waitkey() is to ensure the player or user has time to respond before you continue operation - for instance, time to read a screen full of information before that screen is cleared and another screen is displayed.

Oldefoxx

(Posted 2003) [#4]

I've done some extra coding in this area, so I can give a bit of extra insight now. First, on my PC (an HP), there is no Getkey() returned values for the numeric keypad, arrow pad, or the document paging pad (Inst, Delete, Home, End, Page Up, or Page Down keys). I am not sure why that is, unless they correspond to dual-byte return values.

You see, the operating system either returns one byte or two byte values - if two bytes, the first byte is always a zero. Two bytes usually refers to extra codes needed if the Ctrl or Alt key is also pressed at the same time.

The ASCII code table goes up to a count of 127, and above that, up to 255 (the maximum count within one byte), some BASICs include a range of graphical or special symbols, such as a PI sign or Sigma summation key, or just a series of patterns for constructing lined or shaded borders. There is no standard for the use of codes above 127, so these can be replaced with other meanings.

One neat trick is to take two byte values from the operating system, and recode them to occupy the count range from 128 to 255. Then you can treat them as a single byte value instead of two. This will be how it is done in another BASIC:

   ;OTHER BASIC             BLITZ
   DO                               ;instead of REPEAT
     a$=INKEY$                      ;instead of a=GetKey()
   LOOP UNTIL a$>""                 ;instead of UNTIL a>0
   a=ASC(RIGHT$(a$,1))+(127 AND LEN(a$)=2)  ;no equivalent

Since you don't get characters as a string, you do not know how many characters there were. And since Blitz's GetKey() returns so many characters as value zero, which also represents no key pressed, you do not have any way of knowing what the unrecovered second byte value would have been, or if a key had been pressed.

You can of course use the KeyHit() and KeyDown() information to determine if any key was hit and how many times since you last checked, ir if a hit key is still down, but you might find it difficult to reconstruct which order they were pressed in and to convert from scan code back to ASCII.

Blitz's treatment of the keyboard is ideal for game play, where any struck key can be used to flag steering or firing action, but is less than ideal for getting the results of any key press. Further, the scancodes returned still have to be evaluated to determine if the Ctrl, Alt, or Shift keys were active when the keypress took place so that you can determine if an alternate key meaning was involved (lower case letter in place of upper, for instance).

A reasonable alternative is to look to using a DLL to get the keyboard input from the operating system and return its ASCII or numeric representation to you. But this would have to be written in another language. Fortunately, the DLLs that come with each Windows operating system includes routines to provide this information. Unfortunately, the DLLs that come with the operating system are quite extensive, and the documentation (massive though it might be) is quite terse and hard to follow. So the best course is often to find someone else's work where they have solved that problem, and adopt that code as part of their project.

I am still working on my own version of this approach which is not yet ready to publish, but I am outlining an approach for someone else to follow to more immediate success.