From: "Larry Gilbert" <[EMAIL PROTECTED]> > The secret seems to be doing a whole bunch of ErrFatalDisplayIfs on the > field in question to make sure it was the type, size, etc. that I > expected it to be. After adding enough of those tests (all of which > pass), now the field behaves normally. > Be careful here. Crashes which go away when you change the code are often memory corruption. This sort of bug is often an uninitialised or corrupt pointer that is writing over memory at an offset. The crash occurs because the over-write destroys important data or writes over program code. When you add debugging lines you change the size of your compiled code which can shift the offset of the over-write to a section of memory that isn't important (or which you aren't testing).
Although this will seem to have fixed the problem all it's done hide it. It could surface at any time, either because of a tiny code change the morning of an important demo (computers are evil) or, more often, when an untested section of code makes use of the memory that is now being corrupted. Worse still, in different versions of the code the corruption might affect different data, making it look like different bugs. This can chew up a lot of support time. You might not have a problem like that but from experience I can say that if you do then you really, really want to find it and fix it. All I can suggest to that end is doing your homework - - make sure that all pointers are initialised, that all freed pointers are cleared to prevent re-use, that all memory copies honour the bounds of the destination, etc, etc. If it seems to be that field try looking at the memory that makes up the field structure and looking for properties that seem to be corrupt. Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
