| It would be pure fantasy to believe ActionScripts always work exactly as planned. Just as it's easy to forget a comma or to misspell a word when writing a letter, it's easy to make mistakes when writing scripts regardless of how familiar you are with ActionScript. However, unlike your letter recipients, Flash is unforgiving when it comes to script errors. In scripting, errors mean bugs, and bugs mean your script either won't work at all or won't work as planned. Luckily, Flash provides some handy ways to test scripts and stamp out bugs. If electricBill2.fla isn't already open, open it now. This is the file we set up in the last exercise. In this exercise, we'll test the project's functionality from within Flash's testing environment.
From Flash's menu bar, choose Control > Test Movie. This command creates a fully functional version of your exported movie and displays it in Flash's testing environment. Although there are all kinds of ways you can test your movie in this environment (determining overall file size, streaming capability, and appearance), we're interested in testing its interactive features which means doing everything we can to mess it up.
TIP Enlist as many friends and colleagues as possible to help you test your project. This way you have a greater chance of testing every possible scenario and thus finding all the potential bugs. Enter various amounts in the "Enter the amount you would like to pay:" text field, then press the Pay Now! button. Enter an amount less than 60. If you enter 35 in this text field, the message, "You underpaid your bill by 25 dollars" should appear and the stamp_mc movie clip instance should show the Underpaid stamp. Enter an amount more than 60. If you enter 98 in this text field, the message, "You have overpaid your bill by 38 dollars" should appear and the stamp_mc movie clip instance should show the Overpaid stamp. This is what should happen. What really happens is that the message shows an overpayment of 38 dollars, not 38 dollars. We log this bug as an error and continue testing. Enter the exact amount of 60. If you enter 60 into this text field, the message, "You have paid your bill in full" should appear and the stamp_mc movie clip instance should show the Paid in Full stamp. Erase everything in this field. If you do this and press the Pay Now! button, you get a message stating, "You have paid your bill in full" and the stamp_mc movie clip instance will show that you paid your bill in full. Obviously, this is wrong; we log this as an error and continue testing. Enter some text. If you enter anything beginning with a letter and press the Pay Now! button, you get the message, "You have paid your bill in full" and the stamp_mc movie clip instance will show the Paid in Full stamp another obvious mistake, which we log as an error.
TIP When you find bugs while testing a complex project, sometimes it's best to stop testing and begin the bug-stomping process immediately (as opposed to logging several bugs first, then attempting to fix them all at once). The reason is that when attempting to eliminate a bug, you may unwittingly introduce a new one. Fixing several bugs at once could result in several new bugs obviously not what you want. By fixing bugs one at a time, you can better concentrate your bug-squashing efforts and avoid a lot of needless backtracking. As you know, our project contains three bugs: If a user overpays his or her bill, the overage is shown as a negative number in the custom message that is displayed. If a user chooses not to pay anything, our project functions incorrectly. If a user enters text rather than a numeric value, our project functions incorrectly.
Let's consider why these bugs occur. In the case of the first bug, we know that the numeric value that appears in this dynamic message is based on the value of the difference variable that's created when the script is executed. In addition, we know that the problem occurs only if the user pays more than the amount of the bill. Thus, the problem lies in the way difference is calculated when the user overpays his or her bill. We'll review that part of our script. As for the other two bugs, our script is set up to act in various ways when executed, depending on what amount the user enters to pay. However, we forgot to account for the possibility that the user might not enter anything, or that he or she might enter text, both of which cause our project to act funny. We'll make a slight addition to the script to account for this possibility.
Close the testing environment and return to the authoring environment. Select the Pay Now! button and modify Line 9 of the script, which currently reads: var difference:Number = amountOwed - amountPaid; to read var difference:Number = amountPaid - amountOwed;. 
In reviewing the section of the script that determines what happens when amountPaid exceeds amountOwed, we discover that difference is calculated by subtracting amountOwed by amountPaid. How is this a problem? If the user pays 84 dollars, the difference being calculated is 60 84 (or amountOwed minus amountPaid). Subtracting a larger number from a smaller number results in a negative number. To fix the problem, we simply switch the position of amountOwed and amountPaid in the line of script that sets the value of difference. Now, the smaller number is subtracted from the larger one, resulting in a positive number.
NOTE You don't need to modify the other area in the script where the value of difference is set, because that area is only executed when the user pays less than he or she owes, in which case the value will be calculated properly. With the Pay Now! button selected and the Actions panels still open, make this addition and modification to the if statement: Addition: if (isNaN (amountPaid)) { message_txt.text = "What you entered is not a proper dollar amount. Please try again."; }
Modification to what used to be the initial if statement: } else if (amountPaid < amountOwed) { var difference:Number = amountOwed - amountPaid; stamp_mc.gotoAndStop ("underpaid"); message_txt.text = "You underpaid your bill by " + difference + " dollars."; }
Notice that with this addition and modification, what used to be the first condition that was analyzed has now been relegated to the second condition. Modifying the script in this way will cause this new condition to be analyzed first. 
This addition allows the script to deal with the contingency that the user enters nothing or enters text as the amount to pay. It says that when the Pay Now! button is pressed, if the value of amountPaid is not a number (or isNaN), do nothing in the scene but display a message that asks the user to enter a proper dollar amount. If the amount entered cannot be converted to a numerical value (for example, "frog") or if the field is left blank, this part of the script executes. The isNan() function is another special tool that ActionScript provides to take care of simple yet critical tasks. Notice that instead of inserting a literal value between the parentheses of this function (such as "cat" or 57), we've placed a reference to a variable's name (in this case, amountPaid). This causes the value that the variable holds to be analyzed. NOTE The isNaN() function and its uses are covered in greater detail throughout the book. We made this the first condition to look for because it's the most logical thing to check when the script is first executed. If the user enters a numeric value, this part of the script is ignored and the rest of the script works as expected.
From Flash's menu bar, choose Control > Test Movie. In the exported test file, enter various amounts in the "Enter the amount you would like to pay:" text field and press the Pay Now! button. At this point the movie should work properly under all circumstances.
Close the testing environment and return to the authoring environment. Save this file as electricBill3.fla. Congratulations! You've completed your first lesson.
|
