It only goes to the invalid input method. I looked at the code and removed the part that restarts the program, in relation to the confirm details button and I removed the trigger. Although the invalid didn’t run the method that was meant to didn’t; this must mean my if statements comparison is wrong.
I then switched the statement to check the condition of the second stage. It came up with a unhandled format exception. I forgot the syntax “.text” for reading from a textbox
Note; there is no need to check the customer detail details for formats and size exceptions. This is because even if the user doesn’t type the ideal input, it can’t break the program no matter what. As the input is only going to be collected and displayed. If the brief required more user guidance, I would have had to add a checking system.
After completing entering and confirming customer details; put a letter in pizza choice textbox and click next
Invalid input should appear in a message and after exiting that message it will be as if the user didn’t enter the invalid piece of information
There was no handling of this exception. For some reason I put the line of code just above the try catch, I moved it down to fix the problem.
But after that I noticed that when the program prepared for a new order, the last input in the pizza choice text box was still there. So I added code to clear it on the start=up method.
Doing this I also noticed the progress counter was one out. It starts at one then it change to one without an extra space. Setting the variable to one by default fixed this.
During the above I noticed that the menu doubled up after the program is restarted a few times.Because this has to be written on the first time but not after, I clear the label every reset. Another option could have been a counter and if statement.
No comments:
Post a Comment