Today there was yet another badly reproducible bug in one of my applications. As all of the post-mortem trace was outside my code and only a single line inside one of the components I immediately suspected it.
The bug had to with pressing a key to destroy a component on which the focused control resided. As in this 3rd Party component a message loop was replaced I suspected that the error was caused by a call into a destroyed and thus invalid component’s message loop.
But after removing the code that led to replacing the message loop and some tedious testing I still got the error, this time deep inside the Borland Delphi Runtime Library.
It seemed like a DoKeyUp routine returned false with as possible causes a destroyed or no parent form and some other sanity tests. One of the things besides some sanity checks was to invoke an event handler in the calling program (my program).
After some testing I managed to halt the debugger in this routine and saw it go a route I didn’t expect. But how to prevent this, reading the online help didn’t give a clue. But after reading through the 10-15 lines of code very carefully something attracted my eye. The DoKeyUp routine would also exit normally if I ate the key in my program by replacing it with a null character.
This behavior of the OnKeyUp Event wasn’t in the otherwise very good Borland Delphi Documentation, but carefully reading the sources helped.