John has a good point here. Re-Sizing an array requires re-allocation of 'memory', which takes time. On the other hand, doubling can be a very hazardous process. As one of the kings pharoahs of Egypt is said to have learned when attempting to just double the grains of wheat for each square on a chess board. And ended up owing more grains of wheat than existed in the kingdom (and that was starting with just ONE!
Many of us do the standard 'trick' of just incrementing the array on each pass of adding information. This is inefficient AND fails to reslove the problem of growth without bounds. In many situations, both issues are nit picks, and I have been acused of being one of the pickiest nits around. In 'REAL" programming, the nits are often the difference between sucess and failure, so I can only thank John for - once again - reminding the readers of the pitfalls (and nits to pick?) which abound.
Way back when. In the dark ages of my 'education', we were taught to always estimate the size of things before getting to involved with the details. Granted that these 'estimates' were often wrong, they still served to at least give a reasonable bound or expectation. I often still do this. In EscapeUK's case, it would appear that he does have an upper bound of sorts ("hundreds" should probably NOT go over 1000 - at least without some advance notice / warning), so it might be reasonable to allow the array to start with a number which will hold the majority of his 'occassions' (such as 50?, 25?), and let this double until it was over 1000 (only a FEW times. At that point, I would at least force the user to acknowlege that the process was encountering an unusual situation, even if this is only a msgbox. MichaelRed
mred@att.net
There is never time to do it right but there is always time to do it over