Detecting Capital Letters using k=Key(x)

[CW]

In my latest project, I don't want to pause program flow to wait on an INPUT or a KEYWAIT command. I need to handle input in real time and I want to make use of K%=KEY(x) to do it; scanning through all permissible input values. My question is this. How can I tell an uppercase letter (or character) from a lowercase letter? GL-Basic's KeyCode utility returns two values for a shift-letter, but how can I make use of this fact with KEY(), which only returns a single value?

I could use K$=INKEY$, convert K$ to ASCII, and then compare that value to permissible inputs, but the KEY() is supposed to be swifter. (I'm trying to avoid the overhead that comes with strings.) So before I go the INKEY$ route I figured I would ask you guys how you all handle this challenge. Is there an elegant way to detect capital letters using the KEY() command?

Thanks all.
-CW

[kanonet]

I think you need something like:

Code: (glbasic) [Select]

IF KEY(30)
IF KEY(42) OR KEY(54)
k$="A"
ELSE
k$="a"
ENDIF
ENDIFBut you would also need to handle caps lock (KEY(58) has changed in the past?) and you need to keep in mind, that different language keyboards have different scan codes, like KEY(21) is Y on English keyboard but its Z on German keyboard. So all in all its a bit of work and just using INKEY$() might be better.

[Moru]

This is a plug-in solution for this problem:

http://www.glbasic.com/forum/index.php?topic=679.0

There are even better versions of this code too if you search for keyhit on the forums. (Make sure to go to the first page of the forums before you search)

If you are coding the movement keys for your game, it doesn't matter what keyboard it is, it's the location of the keys you are interested in. AZERTY keyboards will still be controlled with the same physical buttons as a QWERTY or QWERTZ keyboard. Or DVORAK for that matter.

[CW]

I think I see the method. Thanks Kanonet and Moru. 

Caps are important to me as I'm trying to code a swift yet flexible user-input for text & characters with a custom cursor and a hard limit to the number of input characters in the field. My current project doesn't really *need* all this, but I have a vision in mind and must try to see it through. If successful, the result will be a boring, blinking cursor, as bland as tofu. But this will open the door to future possibilities, such as a cursor which creeps, inch-worm like, across the page as you type, has attitude, does somersaults, changes colors, and gets eaten by a bird which then flies away. This sort of input routine can open the door to things such as typing games with sound, where graphics explode in the background in instant response to mistyped characters. Or the computer can be freed to parse previous inputs or attend to other tasks while waiting for the user to type the next command. I mean, How fun could that be?

That's the trouble with visions of games not yet written. Trying to code functions general enough for multiple applications creates a lot of headaches which could be avoided. But then, if you never stretch as a programer, you never grow. Bland Tofu can be good for you!

-CW

[kanonet]

Keep us updated how you progress with this, especially if you make better experience with scancodes(KEY) or ASCII(KEY). Btw if you go with scancodes, maybe my keydef aproach is interessting for you, as it has INIs that contains the keycode to "caption" conversion for US/UK and German keyboards (and could easily get extended to other keyboard designs.

[CW]

I've been looking over your keymap program Kanonet, and I am very impressed. Yours is a wonderful basis for implementing alternate keymaps, alternate languages, and alternate character sets  to GLbasic. Very nice! It more compliments than solves my intended goal, so I'll have to press on. I will keep your utility in mind for future projects where an alternate keymap is handy.

Thanks,
-CW

[Moru]

Ah, there the better version was. I knew you had made one but could not find it on a fast search. Thanks :-)

[CW]

Addendum:

Having studied the problem for a day I have concluded that the best approach for speed and for the handling of both upper and lower case char sets for my project is to use both the INKEY$() and ASC() commands. Trying to avoid the use of one or the other through key() would be counter productive because I would wind up having to reinvent the wheel through BASIC code, only to see a major reduction in processing speed for my troubles, rather than finding a gain. (Not to mention all of the ugly and pointless bloat.) Key() has its uses, but trying to leverage it in an attempt to avoid string handling is a pointless and futile effort. Maybe a gain could be found using inline C++, but trying to do it in Basic is a non-starter. When you come right down to it, GLbasic does what it does VERY well. Now I have a direction for my code.

-CW

[Moru]

Yes, key() is used for specific game control purposes. Any string input has to be done the inkey$()-style to support all strange keyboards out there.

Very simple non-blocking input routine:
http://www.dream-d-sign.de/xmlhelp.php?lang=en&id=43&action=view