Due: 10:00 A.M., Monday, 11/17/08

In this assignment, you are to implement some of the commands that are displayed in the dropdown list under the File menu. These commands should work as they did in Program 8. The only difference is that now the user interacts with the program through graphics components in the window. It can all be done with various kinds of textboxes, but you may also want to use some buttons, checkboxes, or radio buttons. The choice is up to you. The main criterion is that the program should be easy to use. The commands are:

1. start
   There are three cases:
   (1) No game is in progress. In this case, a new game begins, with the pieces placed as they should be at the start of a game. (You don't have to display the board in this assignment, but your program should initialize whatever variables it uses to represent the board.)
   (2) A game is already in progress, but it has not yet been saved to a file.
   The user is asked if the game should be saved.
   If the user responds yes, then the user is prompted for a filename.
   If the filename already exists, then the user is asked whether the file should be overwritten. If the user responds yes then the game is written to that file.
   If the file does not exist, then it is created and the game is written to that file.
   (It's up to you how this is done. The window could have a textbox for entering the filename, which could also be used to enter "yes" or "Y" or other variation like that, or there could be buttons or some other kind of graphics component. The main criteria are that it uses graphics components and not the command line, and it is easy to use.)
   Then a new game begins, with the pieces placed as they should be at the start of a game.
   (3) A game is already in progress, and it has previously been saved to a file, either during this run of the program or some previous run.
   The user is asked if the game should be saved. If the user responds yes then the game is written to that file.
   Then a new game begins, with the pieces placed as they should be at the start of a game.
   
2. resume [filename]
   Three cases:
   (1) No game is in progress. Then the game that was saved in [filename] is read in, and it is resumed. (If no filename was specified, then the user is prompted for it.)
   (2) A game is already in progress, but it has not yet been saved to a file.
   The user is asked if the game should be saved.
   If the user responds yes, then the user is prompted for a filename.
   If the filename already exists, then the user is asked whether the file should be overwritten. If the user responds yes then the game is written to that file.
   If the file does not exist, then it is created and the game is written to that file.
   Then the game that was saved in [filename] is read in, and it is resumed. (If no filename was specified, then the user is prompted for it.)
   (3) A game is already in progress, and it has previously been saved to a file, either during this run of the program or some previous run.
   The user is asked if the game should be saved. If the user responds yes then the game is written to that file.
   Then the game that was saved in [filename] is read in, and it is resumed. (If no filename was specified, then the user is prompted for it.)
   
3. save [filename]
   Three cases:
   (1) No game is in progress. This is an error.
   (2) A game is already in progress, but it has not yet been saved to a file.
   If [filename] is not specified, then the user is prompted for a filename.
   If [filename] does not exist, then it is created, and the game is written to that file.
   If [filename] already exists, then the user is asked whether the file should be overwritten. If the user responds yes, then the game is written to that file.
   (3) A game is already in progress and it has previously been saved to a file.
   If [filename] is not specified or it is the same as the file that the game is already saved in, then it is written back to the file.
   If [filename] is specified and it is different from the file that the game is already saved in, and [filename] does not exist, then it is created, and the game is written to that file.
   If [filename] is specified and it is different from the file that the game is already saved in, and [filename] exists then the user is asked whether the file should be overwritten. If the user responds yes then the game is written to that file.
   
4. quit
   If no game is in progress, then the program terminates.
   If a game is in progress, then the user is asked whether the game should be saved. If the response is yes, then the game is saved as in the save command. Then the program terminates.

Your program must follow these implementation restrictions:

• Your main method should be in a class named TestChess.
• You must use the Java classes in java.awt and javax.swing to implement your GUI. Some of you may have systems that allow you to "write" GUI programs by using your mouse to create graphics objects, i.e., without writing code. Do not do this. All the code in your program should be text written by you. (Of course, you will need to import and use many Java classes.)
• The program should interact with the user entirely through GUI components such as windows, menus, buttons, text boxes and so forth. The details are up to you; the main criterion is that the commands and responses should be easy to understand and use. The only time the command window is used is to initiate execution of the program.
• All game files should be kept in a folder named GameFiles, which should be in the current directory.

Your grade will be based on how well you design and implement the code, how thorough your error handling is, on good programming practices, and on thorough testing. Coding guidelines for Java programs are posted here.

Add comment documentation to your program (all classes) and use javadoc to extract the documentation into an HTML file. Include a javadoc comment for each class and each method. The class comment should include your name and the date (use the @author tag). Method comments should briefly describe the purpose of the method, its arguments, and what, if anything, it returns (using @param and @return as appropriate).

The physical location of the javadoc comments is critical. A class comment must immediately precede the line containing the keyword class, and method comments must immediately precede the method.

When you have commented your source files, run javadoc to create the .html files and view them in a browser of your choice.

• Turn in a hardcopy printout of your java source file TestChess.java and any other .java files your program uses.

  Do not give me a copy of the javadoc.html files.

• All Java programs will be submitted by copying (or ftping) them to a specially designated directory in AFS. Each person in the class has a subdirectory which has the same name as your login in /afs/cu/class/cs242/fa08

  Within this individual directory, create a subdirectory named p10. Copy only the source files and an executable JAR file into this directory, not class files or javadoc files. So, for example, if your login name was smithjd then the files TestChess.java, TestChess.jar, and any other .java files your program uses should be copied to /afs/cu/class/cs242/fa08/smithjd/p10. These directories have permissions set so that no one other than yourself and Prof. Lynch can read the files. You may, of course, use whatever operating system and compiler you wish to develop your code, but the version you turn in, both hardcopy and the files submitted to AFS, must compile and run under JDK installed in the Clarkson ITL (our lab room).

  I should be able to run your program by downloading TestChess.jar into any folder and entering the command line

  java -jar TestChess.jar

• Correct execution. The program must follow all the specifications above.
• Correct implementation. The program must follow all the design requirements above.
• Error checking. You have to figure out what kinds of errors your program should check for, and how it should handle them.
• Readability of the code: commented and well-structured, so that it is clear what the code is doing. Use an accepted programming style. The style of the text is fine, or you can follow the Code Conventions. Whatever you do, be consistent.
• Appearance of the graphics. This is more important than it has been with the previous programs, and it will continue to grow in importance with the next programs.
• Human factors. An inexperienced user should be able to run the program, and the program should interact with the user with clear, understandable prompts and responses. This means that the user will always be able to tell whether or not a command was successfully executed, and if it was not successful, the user is told what the problem was.
• Timely submission of your program. All hardcopy must be turned in by the deadline. Late programs will not be accepted. Printouts submitted electronically will be ignored.