* use _dimmedVarsOnly on COMPILE like this you'll find vars that you haven't declared that may be stepping on the memory footprint of vars you did declare
* use _noRedimVars on COMPILE like this you can't use the same name for a var in 2 different places. You may find that a var you think has a value, in fact has a different one.
* use _caseInsensitive on COMPILE you may have declared 'myVariable' and 'MyVariable', these can or cannot be the same.
* use _dontOptimiseStr if you use 'my text' in two different places, FB will just reference the second use to the first one, but you may need them to be different entries.
* install MacsBug and use _macsBugLabels take this out in the final build, but during debugging it helps to know where you are when you drop into MascBug.
* put CLEAR before each and every of your FNs to be sure that all vars are inited at zero.
* look at each FN and decide if you can make it LOCAL MODE, thus avoiding the risk of accidentally sharing variables with another part of the app.
* if you pass an address to an app, do you need the address or the data?
CLEAR LOCAL MODEIn this case it is the address of the window pointer that is
LOCAL FN myDoSomething( wndPtr&)
t;8 = wndPtr& + _portRect
CLEAR LOCAL MODEIn this case, passing the address was only a means for getting the info once in the FN. IF you didn't use the @, you would be copying in random info (well the address, not the rect actually).
LOCAL FN myAnotherThing( rectPtr&)
t;8 = @rectPtr&
* on a similar note check whether toolbox calls need a value or the memory location of that var. Also check that you're not using Handles in place of Pointers and vice versa. If you're using Handles do you need to lock it in memory (general rule Yes Do it). Do you check each OSERR (or similar) on toolbox calls - you might be assuming somethings going well but...
* put one command per line, removing colons ':'. (This is not bad. It's just damn hard to debug when you change 25 different vars on one line, putting them all separately allows you to walk thru them).
* try and break long FNs up into page long FNs (the length of
your page may vary, but the idea being that you don't need to scroll to visually emcompass a self contained code block.
When this is all OK, then check 'Check for string/array overflow'in the prefs. You can take this off when you do the final build, but when in beta, and even more so, when in debugging, you need to know if you referenced item 14 of an array that you DIMmed as only having 12 members.
Having done all the above you can start looking for _your_ bug. (all the above has done is make sure that your code is clean of the basic mistakes, preparing for trouble shooting).
In your case the error occurs before you beep. So you would be looking at code that happens before. Code that only gets called at closedown can safely be ignored, for the moment (this doesn't mean that the code is good nor clean, just that your current bug can't be there as your app hasn't been there when you bomb).
You should know exactly how much space each var takes in memory and what the values should be. Lauch your code with DebugII and step thru. At the end of initialisation do all your variables have the value they should? Look particularly at arrays, dumb arrays(1), variables that are set to zero using 'var;0'.
(1) see Rick's recent explanations of 'DIM rect;0,t,l,b,r', if you haven't DIMmed the right amount of memory, as in the DIM AEdesc& problem that came up recently, you'll be writing over the variables that follow in memory, not the one you think.
Use liberally the DebugII to break on changed command. Step thru from the beginning, checking each var. It would seem that Debug II lists the vars in its window in ascending order in memory, so put break on change on the vars AFTER you var you expect to change next - then if you're overwriting memory elsewhere you have a good chance to catch it.
Hopefull this will help you find some interesting problems. Not necessarily your bug, but at least you'll have fun on the way.