COP4226 Assignment 4

Extra Credit (due 11/30)

Due Sunday, 12/2 (late 6am 12/3)

Zip your entire project and upload on the web. Exclude the Debug and Release directories.
Submitting Homework Online. Be sure to include any additional projects that you use, when you submit the homework

This application will be an example of a Multiple - Single Document Interface (Multi-SDI) application. It will run a car race in a separate thread in each main form. One race can be running in each top level window. The thread will run a simulation of a race. Every second will be the equivalent of several laps. The number of laps per second is controlled by a trackbar. Data binding will be used to tie all of the data together. There will be a list of national drivers and local drivers that can be added to a race. There will be data classes to encapsulate all of these concepts.

Be sure that I cannot crash your program. This means that you will need to implement validation appropriately. Do not swallow exceptions! If something goes wrong, be sure that the appropriate exception is thrown.

Be sure that dialogs open in appropriate places. Use docking, anchoring, splitting, minimum and maximum sizes to control the appearance of your application. Use your base classes and user controls from previous homeworks to improve the appearance of your application.

Under no circumstances should any child form access any part of a parent. Use interfaces appropriately.

Implement encapsulation. Separate the view from the document.

Under no circumstances may a thread access a variable that is not local to the thread. Pass a custom class between the thread and the thread that called it.

Multi-SDI

Create a single instance application context that will allow multiple top-level windows to be opend.

• It should create the Add Driver modeless dialog when constructed. Be sure that it is disposed of properly.
• When the application is closed, it should serialize the current list of national drivers to a file in the application. Create a setting for the name of the file. Do not ask the user for the name of the file.
• When the application is opened, it should try to deserialize the list of national drivers. The first time the application is run, there will not be a list of national drivers. You will need to run the program and add some names to the national driver list. When you close the application, the list will be serialized. The next time you run the app, you will be able to see the list of national drivers in the modeless dialog.
• Create one Oath and one About dialog. Each top level form should reuse the About and Oath dialogs. Use only one Oath dialog and one About dialog for the entire application. Be sure they are disposed of properly.
• When the context opens for the first time, display a new race dialog. If the user cancels the dialog, then be sure your form closes properly. If the user enters race info, then create a new top level form with the race info.

    public interface IContextInfo
    {
        event EventHandler OpenDriverDialog;
        event EventHandler NewRace;
        event EventHandler OpenAbout;
        event EventHandler OpenOath;
        void AddDriver(Object driver);
        ToolStripMenuItem WindowMenu { get; }
    }
   

    public event EventHandler OpenAbout
    {
        add { aboutToolStripMenuItem.Click += value; }
        remove { aboutToolStripMenuItem.Click -= value; }
    }

    ((IcontextInfo)this.MainForm).OpenAbout += new EventHandler(about_Open);
   

Top Level Form

Create a top level form that implements the Context Interface. The top level form should never access the application context. The application context will create all new top level forms and will access what it needs from the top level form through the interface.

• File Menu
  • New - Create a new race. Implement the NewRace event fromt the context interface, that ties to the menu and tool items for creating a new top level form. The application context will use the event to register a handler for creating a new top level form.
    • Display a new race dialog that requires the name of the race and the number of laps in the race.
    • Create a new top level form using the object that was just updated in the dialog.
  • Close
    • Close the current top level form
  • Exit
    • Close all top level forms, one at a time.
• Add a tool strip with an item for New. It should also be registered in the NewRace event.
• Add window menu like the one in the book. The application context should generate the window menu for each form. Use the context interface to connect the window menu from the form with the context.
• Add a Help menu with Oath and About. Declare the Oath and About dialogs in the application context. Use the same Oath and About for each top level window. Use the context interface to connect the click events with the dialogs.
• Pass in the race object that was modified in the race dialog class, in the constructor.
• Add a data grid view.
  • Bind the grid view to the drivers member of the race object.
  • Do not use a binding source for this, bind directly to the object.
  • Make this a target for drag and drop. Only accept race car driver objects.
  • A new driver should be able to be added via the last row of the grid.
• Add an area for controlling the race.
  • Add three buttons: start, stop, pause.
  • Add a numeric up down control for the number of laps in the race. This should be bound to the number of laps in the race object.
  • Add a label for the name of the race. This should be bound to the name in the race object.
  • Add a button for adding drivers to the race. When clicked, it should open the modeless dialog for adding a driver that is owned by the application context. The listbox in the dialog should be bound to the national list that is maintained by the application context. Use the context interface to connect the click event to the dialog.
  • The buttons control a thread that will run a race.
    • Each second will represent a number of laps in the race.
    • A trackbar in the progress are (below) will indicate how many laps are done in a second. Use Thread.Sleep(1000) to cause the thread to pause for one second.
    • The thread may not access any member variables or static variables in any class. It may pass information when it reports progress, by passing a custom object.
    • When the thread is done, increment the number of races for all the drivers in the race and increment the number of wins for the winner. Do not do this in the worker thread, be sure to do it on the UI thread.
• Add an area for the progress of the race.
  • Add a progress bar for the number of laps that have been completed. Update this control as the thread runs.
  • Add a tooltip to the progress bar that shows the number of completed laps. This should be updated every time the value in the progress bar changes. Use the tooltip from the base class.
  • Add a track bar that indicates how many laps correspond to one second in the race.
    • Use a lower bound of 0 (this is the same as pausing the thread).
    • Use an upper bound of between 25 and 100 (your choice). This is the number of laps that will elapse for each second in the simulation.
    • Initialize the track bar with a valid number other than 0.
    • As the value in the track bar changes, the simulation will run faster or slower. Remember, the thread may only access local variables declared in the thread.
  • Add a tooltip to the track bar that shows the value of the track bar. This should be updated every time the value in the track bar changes.
• Add an area for the winner's circle.
  • Drop a race car driver data source into the area.
  • Change all of the text boxes so they are read only.
  • Bind it to the binding source for a race.
  • Update the data with the winner of the race, when the thread ends.

Screen Shots: Image Folder

Video: HW4 Demo