How can I check that Properties linking to components is not "lost"?

I'm using Delphi 2007. Sometimes properties linking to components get lost. This is typically Action properties and lookupdatasets. I have a few times had some emergency bug fixes and sent out a version to customers with a somewhat catastrophic result due to this :-) Anyone know a way to verify that properties that are supposed to be set really are set, or a way to prevent this from happening?

From stackoverflow

• You can assign such values in code, obviously.

  More importantly though, you have to diff every file before committing to sourcecontrol. Always.

  Make sure your dfm-files is text, not binary. Then it will be easy to see unwanted changes before check-in/commit.

  Diffing everything have stopped a lot of potential blunders for me.

  An automatic build and test-system would also give you some confidence in what you deliver.

  mj2008 : The problems I've had with this have usually been links to other forms that are not open in the IDE when a form is saved. I've used a combination of code and build system tests to make sure it works, plus asserts to tell me at development time.

  _J_ : A similar thing happens to me when I use Delphi Project Groups to likn Project Files together. I find that as soon as I use this, database-aware components lose their connection to the DataModule that their table is on. I gave up using Project Groups.

• You want a way to verify if the values are set correctly. Well, you can use unit tests for this. Just initiate a form, compare the properties and done.

  Comparing the dfm's is also a good way ofcourse but it does not take into account changes due to changed defaults or changes in the code.

• Create dunit test project. Run test before release. Sound all bells when test fails.

• You've received several good answers about how to detect when this does happen (up voted). But one way to prevent it from happening (sometimes) is to make sure that you have added all of the referenced units to your DPR. If you open a form, for example, which contains components that reference other components on a data module, and that data module has not been added to the DPR/project, you're almost guaranteed to have the IDE remove those references, because it removes references which it cannot determine are valid. If, on the other hand, the data module is in the DPR, then the IDE will be able to find it, and it is less likely to remove the references in the first place

  Unfortunately, it still happens from time to time, so you still need to take the precautionary measures detailed in the other answers. But this will make things better, if you don't already do this.

• When you add a form, data module or frame to a project, the IDE inserts a little comment "tag" after the unit name in the dpr file. It has been my experience that if for any reason this tag is not present, the IDE is more prone to losing cross-module component references.

  I wholeheartedly support the idea of always viewing differences before each commit to version control, if you are using such as thing.

• I hate to say this but Source Code Control can help in these situations. Even with an emergency bug fix you should be checking everything into a source code repository (Perforce is my personal favorite). In a small fix you could see by what files have changed whether you have any changes you are not expecting.

• I would use OpenCtf It is based on Dunit.

  OpenCTF 1.1 - Component Test Framework Component Test Framework

  The OpenCTF component test framework helps to build automatic tests for all (visual and non-visual) VCL components in a Delphi application. It is based on the DUnit framework.

  openctf_banner.gif

  How does it work?

  * OpenCTF iterates over all specified Forms and DataModules and
  

  dynamically creates DUnit test cases for selected components * Customized test classes detect which components have to be tested, and configure the test steps

  How can it help me?

  OpenCTF provides an easy way to build automatic quality checks for large projects where many components have to pass repeated tests.

  Here are some examples:

  * detect missing or wrong property values - e.g. Buttons without assigned
    Actions, DataSources without associated DataSet
  * detect unassigned event handlers - e.g. missing OnExecute event
  * check that all DataSets can be opened
  * check the tab order
  * find invisible components (e.g. invisible TabSheets which better should be hidden at runtime)