NETD 3202 Skynet Payroll Phase 2

The Scenario

In consultation with Victor, it would be beneficial for the application to actually display totals and other information related to a given pay period. Victor has also expressed interest in a more modern interface with fewer windows popping up (and fewer ding sounds his words), so we are changing the nature of the user interface. The error messages and usability can be improved, and it seems this could be done using exception handling.

This Lab is a direct extension of Lab 1. Ensure you are familiar with the Lab 1 requirements prior to reading and attempting this Lab.

New Form: The Summary Form

• Create a second WPF form that includes labels for displaying total number of workers, total messages, total pay, and average pay per worker for all worker data entered in total there will be eight labels, four for displaying summary data and four accompanying identifier labels
• Add a Close Summary button to this form, and add functionality for this to close the form
• Anytime this form is displayed it should be displayed modal so that the user is forced to click the Close Summary button to return to the data entry form
• This form should not be able to be minimized by any means
• When the Summary form opens, access the property procedures that contain the total number of workers, total number of messages and total pay and immediately display these as well as the average pay per worker in the appropriate label

Design Changes: The Payroll Entry Form

• Add a Summary button that will open the Summary form when clicked
• Add labels positioned to the right or just below the existing textboxes where a user would normally enter the workers name and number of messages these labels will have red text but be empty by default

Code Changes: The Payroll Entry Form and PieceworkWorker Class

• Modify the validation for the PieceworkWorker class so that it has an upper bound of 20000
• At the presentation level, your block of statements that create the object and set its properties should be enclosed in a try statement that will capture an exception thrown by the class definition - in particular you are expecting an argument exception that might be thrown when an invalid worker name or number of pieces is entered as previously described
• If any field is in error in the worker class, throw a relevant exception - for example, when an argument such as Name is in error, throw an ArgumentException this should be done in the property procedures
• Back at the presentation tier check the parameter name of the exception caught, and based on that name:
  • populate the label next to whichever textboxs contents caused the error with a short error message MessageBoxes should no longer be used (except for, perhaps, a general exception)
  • set the offending textboxs border to be red
  • set focus to the offending textbox so the user can correct the error
• After successfully setting all object properties and calling the method to calculate pay, access the Total Pay property procedure for the current object and output it in the total pay label formatted as Currency
• Add functionality so that once the user has attempted to correct an entry error in a red-bordered textbox, the red border goes away

General Function

• Similar to Lab 1, the workers pay is calculated based on the table provided previously
• When a user clicks Calculate Pay, the program attempts to create a new piecework worker object where the input is validated within the worker class
• If either entry textbox contains an invalid value, that field will be highlighted with a red border and a red error message will appear to the right (indicating what was wrong with their entry), and the pay will not calculate
• When the user attempts to correct their entry error, the red highlighting and error message are both cleared
• When the workers pay is successfully calculated, the entry fields and Calculate button should be disabled / greyed out and focus set to the Clear button
• When the Clear button is pressed, the entry textboxes, the result label, and the error labels will all be cleared, the textboxes and Calculate button are re-enabled, and focus is set to the field for entering the workers name
• When the Summary button is pressed, the new Summary form will open, displaying cumulative statistics about the data entered so far; this window must be closed using its Close button to return to the Payroll Entry form

Additional Considerations

• Pay attention to when your labels are cleared, and ensure no incorrect information is ever on-screen
• The program must be adequately documented:
  • functions and event handlers should all have block comments
  • calculations, decisions and iteration should be explained with brief comments
  • there should be a header at the top of each forms code (and any other modules) including your name, the last modified date, and a description
• Adhere to an approved style guide and ensure your variable names and other elements are properly cased and adequately descriptive
• Consider accessibility; this application must be easily usable with keyboard only and any fields the user interacts with must have useful tooltips