• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to link up applet's graphic component with ActionListener?  RSS feed

 
Maciej Plucinski
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone. I am pretty new to Java and I'm working on an applet displaying chess board with pieces. I want my pieces to interact with users thus if clicked they would move on the board. I am not sure if I need to use MouseListener interface or some other, because problem is that pieces move as I want, but when you click on any place within an applet area and obviously it is not as I want. The piece should move (or do any other action) when it is clicked, not when you click the mouse anywhere in applet. I don't know how to limit the MouseListener area thus it matches exactly particular piece? So I want the piece to behave similar way like an object of type JButton for example. Thanks for any suggestions Here is a fragment of my code:


 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My approach would be to have Piece extend JPanel, and then to place 64 of those on a MakeBoard in an 8x8 GridLayout (or 32 of them, depending on what exactly Piece represents). That way, each piece would only receive the actions events specifically targeted at it.
 
Maciej Plucinski
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:My approach would be to have Piece extend JPanel, and then to place 64 of those on a MakeBoard in an 8x8 GridLayout (or 32 of them, depending on what exactly Piece represents). That way, each piece would only receive the actions events specifically targeted at it.


Thanks. You mean to write an inner class in Piece that extends JPanel and override the paintComponent(Graphics g) method, on similar way in ChessBoard class where I wrote MakeBoard inner one?
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They don't need to be inner classes. IMO inner classes clutter up the source code if they have substantial logic - as the ones here probably will end up having. But first you need to decide on an object model - what is a "Piece"? Is it a figure? Then you'd have only 32, and would need to represent empty squares in some other way. They would also be able to move around. Or are they squares on the field? Then you'd have 64 of them, and they wouldn't move around, but might have different figures assigned to them.

Without thinking too much about it, my object model might have these classes:
- Board extends JPanel (1 instance)
- Square extends JPanel (64 instances, used to handle UI actions)
- King (2 instances)
- Queen (2 instances)
- Rook (4 instances)
- etc. for Bishop, Knight, Pawn

These last 6 classes would all implement some common interface through which they could draw themselves on the field, let's call it Figure. That way, all Squares would either have a reference to a Figure (which knows how to draw itself), or not - in which case it'd be displayed empty in black or white.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!