class KeyHandler extends KeyAdapter
{
public void keyPressed(KeyEvent e)
{
//handle keys
switch (e.getKeyCode())
{
case e.VK_LEFT:
block.rotateLeft();
break;
case e.VK_RIGHT:
block.rotateRight();
break;
default:
break;
} //end switch
repaint();
} //end keypressed
}
I''ve also got this in my init() method:
addKeyListener(new KeyHandler());
Does anyone know what would be causing this problem? Thanks in advance.
- Daniel
VG Games
[java] Problem with key event handling
For some reason, the following code works fine when I run my applet in Internet Explorer, but does not work in the AppletViewer.
- DanielMy homepage
Does your call to block.rotateXXXX() change the block some small increment, and then update the screen at the call to repaint in keyPressed()?
In this case, because the keyPressed mothod is only fired when a key is initially pressed, your block will only rotate one increment if you hold the key down, and the screen will not change after that. What you will effectivly get is keyTyped behavior, where you have to type the key repeatedly to see any results.
The usual way I see this done is on the keyPressed(), flag something in the block so it knows it is rotating left, right, or standing still. On the keyReleased(), clear the flag. The screen update will have to be self threaded, because you won''t have any key events to fire your repaint() call.
There was an earlier discussion on framerates that was similar, "Keeping constant framerate".
ManaSink
In this case, because the keyPressed mothod is only fired when a key is initially pressed, your block will only rotate one increment if you hold the key down, and the screen will not change after that. What you will effectivly get is keyTyped behavior, where you have to type the key repeatedly to see any results.
The usual way I see this done is on the keyPressed(), flag something in the block so it knows it is rotating left, right, or standing still. On the keyReleased(), clear the flag. The screen update will have to be self threaded, because you won''t have any key events to fire your repaint() call.
There was an earlier discussion on framerates that was similar, "Keeping constant framerate".
ManaSink
quote: Original post by deakin
For some reason, the following code works fine when I run my applet in Internet Explorer, but does not work in the AppletViewer.
I had the same problem with AppletViewer from JDK 1.2.2 under Windows 95 - it just would not respond to keyboard events.
Have you tried calling enableEvents(AWTEvent.KEY_EVENT_MASK) on your applet? This should be the default behaviour, but it doesn''t hurt to make sure. It didn''t work for me, and I never did find a way around it.
Good luck.
Are you getting the focus first? If not, just add a Mouse adapter with requestFocus() in the mouseDown() function. If so, uh, disregard.
quote: Original post by deakin
For some reason, the following code works fine when I run my applet in Internet Explorer, but does not work in the AppletViewer.
class KeyHandler extends KeyAdapter { public void keyPressed(KeyEvent e) { //handle keys switch (e.getKeyCode()) { case e.VK_LEFT: block.rotateLeft(); break; case e.VK_RIGHT: block.rotateRight(); break; default: break; } //end switch repaint(); } //end keypressed }
I''m quite suprised that this works under any JVM. If that is your actualy code (and not edited for simplicity) then there is no reason why it should work. First, class KeyHandler has no access to any object block. If block is a public static member of another class OtherClass, then you need ot do
OtherClass.block.rotate();
Or you can make a public static method of OtherClass to return it''s copy of block.
OtherClass.getBlock().rotate();
And after all that, the key event codes need to be referenced in a similar manner. Being that they are static variables of class KeyEvent, they should be referenced like so:
KeyEvent.VK_LEFT and
KeyEvent.VK_RIGHT
I have KeyHandler declared within my main object which is extended from Applet. I will try some of the suggestions here... is there an alternative way to get key presses, something which just tests whether a key is down or not? Thanks everyone...
- Daniel
VG Games
- Daniel
VG Games
- DanielMy homepage
Jim_Ross wrote:
>I''m quite suprised that this works under any JVM.
Erm... I think this is an inner class and therefore has access to all of the outer classes'' methods and member variables.
>And after all that, the key event codes need to be referenced in a similar manner.
Any instances of a class are just that, the modifiers just define how the JVM. For example, if something is static, then then the JVM creates one copy which is shared by all instances. For all intents and purposes that static member is contained within every instance. Keyevent.VK_LEFT and e.VK_LEFT are perfectly valid. It''s actually good practice to reference it via the instance variable however, as it may be a subclass which has modified it along the way, (not possible in this case though as it was declared as final in Keyevent).
I know it''s not related to this actual thread, but I just wanted to clear those facts up for anyone who reads this.
>I''m quite suprised that this works under any JVM.
Erm... I think this is an inner class and therefore has access to all of the outer classes'' methods and member variables.
>And after all that, the key event codes need to be referenced in a similar manner.
Any instances of a class are just that, the modifiers just define how the JVM. For example, if something is static, then then the JVM creates one copy which is shared by all instances. For all intents and purposes that static member is contained within every instance. Keyevent.VK_LEFT and e.VK_LEFT are perfectly valid. It''s actually good practice to reference it via the instance variable however, as it may be a subclass which has modified it along the way, (not possible in this case though as it was declared as final in Keyevent).
I know it''s not related to this actual thread, but I just wanted to clear those facts up for anyone who reads this.
"We who cut mere stones must always be envisioning cathedrals"
buh wrote:
>Are you getting the focus first? If not, just add a Mouse adapter with requestFocus() in the mouseDown() function.
Good point, a more direct way of doing that is just doing a call to requestFocus() directly on the Applet''s panel after all the initialization stuff is done. I can''t remember what the specs say about what gets focus when...
Another thing is, I''m guessing you have a class extending Canvas to do all the drawing, perhaps add the KeyHandler to that instead? Also if you only use the KeyHandler the once, you could always use an inner class - they''re a little faster.
>Are you getting the focus first? If not, just add a Mouse adapter with requestFocus() in the mouseDown() function.
Good point, a more direct way of doing that is just doing a call to requestFocus() directly on the Applet''s panel after all the initialization stuff is done. I can''t remember what the specs say about what gets focus when...
Another thing is, I''m guessing you have a class extending Canvas to do all the drawing, perhaps add the KeyHandler to that instead? Also if you only use the KeyHandler the once, you could always use an inner class - they''re a little faster.
"We who cut mere stones must always be envisioning cathedrals"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement