Although you'll be very happy that our modifications last week worked, you'll also be aware that they only just work. There were three problems that I identified at the end of the last session, any of which could cause the program to crash or misbehave.
When I used the word 'bombproof' in the title of this week's session, I meant it. The aim of every program is to present a stable working environment for the user which will not crash or malfunction but get on with the job it's required to do. One of the most important techniques for a programmer to learn in getting towards this goal is what I call 'fence-mending'. Let me explain...
You're a farmer and out wandering your fields/ranch/whatever. As you stroll around you notice a fence that's broken. It's only a minor break and could be fixed in a couple of minutes. You have two options: 1) to think "I'll remember that break and get round to fixing it next week" or 2) to think "I might as well fix it now just in case I forget next week and the break ends up causing a problem". The first approach is the lazy one and the second the correct one. In other words, mend fences/problems as you go in case you never come back the same way again.
In programming terms, we were slightly lazy last week in that we spotted 3 possible problems and didn't stop to fix them, but I only moved on because the session would have been too long. We're going to fix the problems (fences) now just in case we forget to do so next month or next year.
Taking the problems in order, the first is easy to solve. We need to give the program slightly more room to 'breathe' by making our numbers%() array larger, to accommodate more ball numbers. There's no point in being silly and saying 100 etc as no lottery would ever have this numbers and because there would be too many numbers to display properly on screen later on. A sensible maximum number is 8, so go to the top of the MiLo code and change the relevant line to:
GLOBAL numbers%(8) rem Array ....etc.
Whle we're in this part of the program, move a few lines down and set nballs% to 8, so that we can test out this 'worst case' scenario:
nballs%=8 rem Minimum 2 and maximum of 8 balls
Note the extra comment I added, to remind me of the maximum
in future when changing the number. It's always a good idea to include a
comment after every definition statement to explain where a number comes from.
You may know now but will appreciate all the help you can get when scanning the
code in 6 months time! Resist the temptation to translate and run the program,
as the rest of it hasn't yet been 'upgraded' to handle this number of balls.
Our second problem was that the code which saves generated numbers for
posterity is also limited to handling six numbers. Locate the generate: procedure
and add ,num7%,num8% to the CREATE and OPEN lines. Add two more lines before the
APPEND as well:
A.num7%=numbers%(7)
A.num8%=numbers%(8)
Note that even if the number of balls is less than 8, it
won't do any harm to write out zeros from the unused array elements into our
archive file. An analysis program can easily work out how many balls were used
later on by just looking for non-zero numbers etc. Translate and run the
program and generate a set of numbers.
It crashed, right? The error it gave should have been "Invalid arguments" and the reason it happened was that our archive file was defined with six number fields and now here we are asking for the file to be opened with eight! Something obviously has to give! The cure for us is to delete the archive file (do this now!) and let the program create a new one the next time it is run, with the full eight number fields.
There's another important lesson here which is well worth noting. When defining your file formats and database structures, always allow room for expansion. Think about the possible size of your data sets and use fields and variables that you know full well are zero (at the moment), for at some point in the future you're bound to want to add something and being able to do it without screwing up existing data files will be a very good thing. Those of us who've watched Microsoft's file formats change with every new program version could well wish that they'd learned the same lesson about looking ahead...
The third problem is of course that if there are more than 6 numbers, their display overruns the white box specially cleared for them. It would be easy enough to just make the box big enough for eight numbers, but a more elegant way would be to use a formula to work out a smaller spacing depending on the number of balls drawn.
Still in the generate: procedure, change the gAT line to read:
gAT 60+(i%-1)*(300/nballs%),130
Changing the "50" to "(300/nballs%)" is the important bit.
With nballs% set to the original 6, the fraction comes out at the same value,
but with nballs% set to 8 it becomes 37 and means that the numbers get squeezed
up properly. With less than 6, of course, the spacing is larger and still looks
OK.
If your code has become confused for any reason, you may find
it convenient to download the code from my machine, just to be sure. It's here
as milo14.txt.
Next week we'll make the 'number of balls drawn' and the 'maximum value' both user preferences which can be changed by the user... See you then!
Go to next lesson | Programming index