PizzaApp in VB.NET

The repository for this website is available here.

Version name	Change notes
Add stub screen elements for the order including First/last name Street address and postcode Quantity of pizza orders Crust type (thick/thin/cheesy) Checkboxes for various toppings Cost indicators for the crust type/each of the toppings/total Also set the tab order for the stubs, ensuring they work as expected for the user
Allow argument parsing to construct a PizzaOrder object PizzaOrder objects can be initialised through the New keyword just like other objects. This saves numerous lines of code space Orders are now stored in a List collection, meaning the number of orders can be retreived with orders.Count(), eliminating the need for an ordersCount variable Screen elements were renamed internally from their default values to more accurate descriptions
Version two is focused on the bulk of the functionality, to create the features, but without validation yet
Calculate pizza cost as the user edits the fields and checks/unchecks the radio/checkboxes Tooltips were also added on hover for all screen elements to provide more details Readme was updated from the default one, badges and emojis were added for more colour
The total cost calculations are only updated once the quantity field has been confirmed as valid. An error was occuring where the user would delete the value of the quantity field, causing the calculation event to fire, and the program would break as an empty value could not be converted to an integer. This was mitigated through the use of the IsNumeric function, which means the calculateTotalCost function is only run when input can be resolved as valid.
Use a dictionary to expand the crust type and pizza topping codes back into their original forms. E.g. c to cheesy and pin to pineapple. A ternary operator (If can be used as a function in VB.NET) was used to evaluate an edge case when the program attempted to expand an empty list to toppings. Because of the string splicing used, the program could potentially break. However, with this implementation, the program will return a default value of No toppings selected (View release on GitHub for more information)
The subroutines for calculating the cost of toppings, crust, and the total cost, have all been converted in functions, allowing them to return values. CalculateCrustCost will return a single Char which represents the selected crust type CalcualteToppingsCost returns a List of codes representing the shortened names of the selected toppings CalculateTotalCost will return the total cost of the order, which can be attached to the PizzaOrder object at a later date.
Order details are now concatonated in a much more aesthetic manner. Each is as follows The name of the person ordering, along with the order date and time The delivery address and postcode of the order, along with the telephone number The quantity, crust type, and toppings on the pizza A future version may implement: A cost indicator for each order in the list A boolean indicating if the order has been completed, and delivered
Version three is focused on validation of input fields
Validate first and last name fields The first and last name fields will be validated as non-empty on form submit. I decided to do it on submit, rather than on change, or on field exit, because those are really annoying when you get the popup boxes while trying to edit other things. The quantity field will also be validated as an Integer rather than Numeric, because Numeric would still validate the input 1.5, and you can't have half a pizza.
Validate date and time fields The delivery date must be at least 20 mins from the time of ordering. If date isn't beyond that time, the program will provide a popup message box asking the user if they want to set delivery time to exactly 20 mins from now.
Don't run update cost funcs while form being reset. I used the debugging functionality of Visual Studio to help preview the values of variables as they change. A runtime error (infinite recursion error) was appearing when the form was being reset via code. The error was occurring where the form was being reset, meaning the TextChanged handlers were running, updating the costs, running the handlers, updating the costs, etc, and the program crashed in an infinite loop. This was fixed by adding a boolean resetting to only run the update cost functions when the form isn't in the stage of being reset
Validate toppings, phone number, and postcode A popup box will appear if the user tries to submit the form with no toppings, assuming it to be a mistake. It does, however, allow them to proceed if they're gross and like margarita. Phone numbers are mainly validated through a masked textbox, allowing for Australian mobile phone numbers in the format 04xx-xxx-xxx The postcode is validated through the use of a regular expression, fitting four digits. It's pretty simple, but effective.
A minor version, the address field will be validated as non-empty, because addresses can be really long and random so it's not worth it to try and validate using regex
Validate the quantity field The quantity field will be validated as an integer of value at least one, through the use of a regular expression. If the user has attempted to order more than 30 pizzas for some reason, the program will confirm with them that they really want to order that many A max length of two characters on the text box also applies.
Fix bugs Finn found in Issue #3, patched in Pull request #4 A branch was used to edit the changes separately to the main code before merging. See branch Blank endings on phone number are still valid First name + last name can have non alphabetical characters Quantity field should be simplified in warnings if putting in decimal places
Version four is focused on ergonomics and extra functionality, such as reading and writing to disk
Set the colour theme of the app to look much nicer than the default windows colour theme. The window icon was updated to match, as a pizza emoji. Titles were made bold for readability and to establish their importance. A popup help message box was also added to display a help message for the user
Implement serialization and deserialization, write orders to file The orders variable can be completely serialized and deserialized without any loss of data. Upon each record change, it is written to a local file in preparation of functionality soon to come (both reading and writing to file) The max date field is also generated to be 14 days from the current date.
Read and write orders to file. Order records can be fully written to and read from the orders.xml file located next to the binary. Buttons have been added on the form to read from the file (allowing the user to edit the file and have the changes be updated in the app) and resetting the orders to the default, to clear the database.
Final touchups on the project so that it may be considered complete. Fix tab order for newly added elements (xml serialization buttons) Add xml help to popup message