KeyListener malfunction

[SavnetSinn]

I'm working on a small game in my free time as a proof-of-concept to myself that I'm capable of learning Java, but I've been stumped on an issue for the last week or two involving the instance of KeyListener I created for my project. Basically, the game has a player moving a small block around the screen with the arrow keys while avoiding other moving blocks on the screen. It all seems to be working rather well, except for the fact that only the 'Up' and 'Left' arrow keys respond when pressed - 'Down' and 'Right' don't do anything.

The KeyListener is an anonymous adapter class:

addKeyListener(new KeyAdapter()
  {
   public void keyPressed(KeyEvent evt)
   {
    switch (evt.getKeyCode())
    {
     case KeyEvent.VK_DOWN: pc.y += 10;
     case KeyEvent.VK_UP: pc.y -= 10;
     case KeyEvent.VK_RIGHT: pc.x += 10;
     case KeyEvent.VK_LEFT: pc.x -= 10;
    }
   }
  });

'pc' is an object of the PCBlock class which defines the player-controlled block:

private class PCBlock
 {
  int x, y;

  PCBlock()
  {
   this.x = width/2;
   this.y = height/2;
  }

  void update()
  {
   if ((x-15) < 0)
    x = 15;
    else if ((x+15) > width)
     x = width - 15;
    else if ((y-15) < 0)
     y = 15;
    else if ((y+15) > height)
     y = height - 15;
  }
 
  void draw(Graphics g)
  {
   g.setColor(Color.GREEN);
   g.fillRect(x-15,y-15,30,30);
  }
 }

My assumption is that the problem I'm having lies in either of these two classes. Can anyone spot what I'm doing wrong? If more of the code is somehow necessary, I'll post it.

[Taywin]

Hmm... I don't know where you get the 'width' and 'height' from... By the way, line 17, I am not sure that you need 'else if' for y because it looks like you should check x and y separately. In other word, shouldn't it be 'if' instead?

[SavnetSinn]

You're right, I could change that "else if" to simply "if". But I'm assuming that it won't help by itself. I'll give it a shot.

Height and Width are determined earlier on in the program, and they get the size of the window or applet containing the content pane.

[jon.kiparsky]

First thing in debugging is to identify the actual problem. In this case, it's one that every programmer in a C-type language commits early on, and I'm going to let you find it yourself, because the facepalm you will undergo will mean you never make this mistake again.

The most basic fault diagnosis technique known to computer science is simply to print out values at points in the code where things should happen, and see what's actually happening.
In this case, you want to print out the values of pc.x and pc.y each time they're changed, and then run the program and push keys.

You'll see it in about half a second.

[SavnetSinn]

You, sir, are a genius, or at least a great teacher.

[jon.kiparsky]

Glad to help. Now go do something about those public fields (pc.y and pc.x). You don't want public fields hanging out all over the place, you never know what might happen to them. Make them private and provide methods to modify them.

This, for example, will allow you to rotate your frame of reference: rather than setting x and y coordinates, now you can say "move up" or "move down" which then can translate to "move forward" (in the direction I'm facing). A little trigonometry (which I'd have to review, I'm not good at that sort of thing) will then allow you to set an angle and calculate what it means to "move forward by 10" when you're rotated, say, 37 degrees from zero - and that calculation happens once, in your pc class, and the rest of the game doesn't have to think about it.