getkey

Get a single keypress (v1.3, jan 2012)

Description

GETKEY - get a single keypress

CH = GETKEY waits for a keypress and returns the ASCII code. Accepts all ascii characters, including backspace (8), space (32), enter (13), etc, that can be typed on the keyboard. Non-ascii keys (ctrl, alt, ..) return a NaN. CH is a double.
 
CH = GETKEY('non-ascii') uses non-documented matlab 6.5 features to return a string describing the key pressed. In this way keys like ctrl, alt, tab etc. can also distinguished. CH is a string.

This function is kind of a workaround for getch in C. It uses a modal, but non-visible window, which does show up in the taskbar.

Tested for ML versions 6.5 and up

• Acknowledgements: This submission has inspired the following:; GETKEYNOW, YESNO, SMARTY: A Vision Based Autonomous Ball Sorting Robotic System, waitinput, GetKeyWait
• MATLAB release: MATLAB 6.5 (R13)

[Chris Brown]

The INPUT function in R13 contains a bug that does not flush the keyboard buffer while within loops, meaning that after so many calls the keyboard will stop working.

As a result, getkey is especially useful to me. Thank you for making it available.

[Dimitri Shvorob]

Chris, could you elaborate please? Running
'for i = 1:100, a = input('Enter a letter','s'), end', I didn't see any irregularities. (How many is so many?)
Jos, maybe you could write a companion function that outputs the key pressed now, rather than waits for one, as INPUT? I don't really know of any way - including via 'currentkey' figure property - to do that in Matlab, and a solution would be very helpful.
Thank you.

[George Aumann]

Just what I was looking for.

[Patrick Craston]

Great! been searching for something like this for ages..

[Erik Helberg]

 

[fred klugger]

How can I use this?

[Jos van der Geest]

to Fred Kluger: you may use this wherever you want a single key response from the user. You can use it in similar way as you would use <input> (which requires an additional "enter")

to Erik: ??

Jos

[Jay Vaughan]

Did the job perfectly for me.

[Jens Rantil]

This program is unnecvessary as it can be done using
[ignore,ignore2,keycode]=ginput(1);

[Jos (the author)]

To Jens Rantil: GETKEY is not at all as trivial as your code implies. For instance, GINPUT needs an axis (and will create one if none exist) and can capture only a few keys.
GETKEY has none of this behavior, and is much more flexible as it can be used in codes without graphical output.

[gregor samsa]

Good job. Worked for me

[Tristan]

 I am driving a virtual robotic arm with getkey. It works but it crashes if I hold a key down. Does anyone know of a way to allow for continuous input?

[Jos (10584)]

@Tristan: perhaps GETKEY is not the best option here. You could create your own key press window and use that in your code. Here is an example:

figh = figure('name','press some keys') ;
set(figh,'windowkeypressfcn','set(gcbf,''Userdata'',get(gcbf,''CurrentCharacter''))') ;
set(figh,'windowkeyreleasefcn','set(gcbf,''Userdata'','''')') ;
t0 = clock ;
fprintf('\nKeys pressed in 5 seconds:\n') ;
pause ;
while etime(clock,t0) < 5,
    curkey = get(figh,'userdata') ;
    if ~isempty(h),
        fprintf('%c',curkey) ;
    end
    pause(.05) ;
end
fprintf('\n') ;
delete(figh) ;

[Aaron]

Hey guys, I know Tristan and told him about this solution, and decided I'd post here in case any one else had this problem. I downloaded the Psychtoolbox (http://psychtoolbox.org/wikka.php?wakka=HomePage) which is free, and it has a command called KbCheck(). It can read keyboard input at any time even during a endless while loop. I drive a mobile robot using the WASD keys using it. Note: KbCheck outputs a weird key code, use KbName to convert to ASCII.

[Aaron]

I should also add that this function doesn't wait for input. So if no keys are pressed when it is called, it is bypassed, which is great for use in a while loop.

[Jeff Vipperman]

Nice, but I have it inside a loop where I assign the ith value of a vector using getkey(). If I hit the CTRL key (to CTRL-C and break out of the loop), it stops pausing to accept input each time through the loop.

[Priyanshu Agarwal]

This function does not work well with a GUI. Once this is invoked repeatedly in a loop in GUI function the focus from the current GUI figure is lost. Is there anything that can be done in such a case?

[Jos (10584)]

@ Priyanshu, This was not designed to work in a graphical user interface. Use keypress callbacks of the gui window instead.

[Catalin Eberhardt]

I have the same problem as Priyanshu, namely I need to be able to read key presses but without losing focus of the current window (which is not GUI but simply a graph!). I am not sure what your suggested solution was, Jos, could you elaborate please?

[Jos (10584)]

@Catalin, a graphics window and a GUI window are basically the same thing, a matlab figure. Both have properties that allow to execute a piece of code (callbacks) when a key is pressed and the figure has focus.

GETKEY is primarily designed to be used when executing code in the command window.

[Catalin Eberhardt]

Thanks Jos. Do you know how I can detect keypresses of the left/right arrow keys? I know it must involve use of WindowKeyPressFcn but I have no idea how to use that in syntax, since there's no example for it in the Matlab help!

[Andrew Bytheway]

Great work.

I made a few tweaks which you may be interested in implementing.

I added the following properties to the figure:
'NumberTitle','off'
'position',[0 -40 1 1]
'Name','Press a key'

On Windows this places the figure off of the screen, instead of behind the taskbar. This will help ensure that the figure is not visible since some users may place their taskbar elsewhere on the screen.

It is also possible for the user to maximize the figure and then close it, which would cause an error when attempting to delete the figure handle. To procect against this use the following code:

if ishandle(fh)
    delete(fh) ;
end

[Jos (10584)]

@Andrew B: Thanks! I've implemented most of your suggestions. A new version should be up soon.
The "position" problem (if any) is, however, not easy to solve, as it seems to depend on OS, display setup, ML version ...