I have a certain window created at run-time. In this window is a table that serves as a master for many other tables on the form. All tables on this form have, as their DatabaseName property, the name of a database component that's in a database module which belongs to the project. To me, that seems like a normal thing to do.
*Sometimes* when I close the window, the form crashes. I have delved deep into the Delphi code several times to try and find the bug. It turns out that a TCollection, of type TFieldDefs, is crashing when it frees one of its FItems, a TFieldDef. I can, by reason, find out which of the TFields in the TDataSet crashed, but I can't find out WHY! Oh, and sometimes it's a different table and a different field...
The program continues to run semi-normally. Closing the program produces more errors, but starting the program again gets the user back on his/her feet.
The good news is that, luckily, none of the data in the tables on the form is ever lost. However, no more windows of that type can be created at run-time. An error appears saying that a component by the same name cannot be created. I've tried circumventing this side-effect to no avail. I want to nail the problem at its heart anyway, not treat the symptoms.
Since I do not explicitly free any objects that belong to the form, I don't think I'm at fault. In fact, my call stack confirms this plea of Not Guilty: every call in the stack is a Delphi-packaged source file. Objects are properly freeing their ancestors before themselves, and they free their children components. Nothing seems wrong. Something must be freeing a lonely TFieldDef on accident. Maybe?
Also, at design-time I have no TFieldDefs. They must be being created at run-time by the datasets.
What can I do to stop my form from crashing?