为什么用“捉妖”这个词？程序开发中，往往会出现这样那样的错误，他们像妖魔一样藏匿在程序的各个地方，而排除错误的过程就像捉妖一样，记录妖魔的特征，分析他们出现的原因，找到它的老巢清除掉。
本文讲述的是捕捉Delphi中StatusBar控件的AutoHint属性的“妖”的过程。
前一段时间做了一个根据文件内容进行查找的文件查找器。由于文件格式是自己定义的，并且实现的是对文件内容有意义的查找，因此不能仅用系统所提供的函数或者Windows的文件查找来实现。
实现了系统之后，为了让它界面更友好，因此决定加入状态条，提示界面功能，显示当前日期以及时间（如下图）。在查找时对查找过程进行提示，于是在窗体上增加了StatusBar，以便在进行查找时显示“正在搜索…”的字样，提示用户搜索正在进行。而如果只对搜索状态进行显示的话，StatusBar就显得有些单薄了，于是就想到在StatusBar中显示各个按钮、编辑框的说明。
我清楚的记得以前实现过这样的功能，于是找到那个软件。果然如此，当鼠标移动到按钮、编辑框等控件上面的时候，StatusBar中Panes[0]中内容自动地更新为控件的Hint的内容，如下图所示。
图中显示的是鼠标移动到最右方的SpeedButton时的情形，图上左下角显示的“退出系统”字样与当前显示的Hint是一致的。
类似地，我在文件查找器项目中放置一个StatusBar，并设置了其他控件的Hint属性，按下F9运行，但结果很奇怪，StatusBar并不能显示控件的Hint。
我想肯定是程序中对StatusBar的操作在文件查找器中没有写入，于是打开例子程序，仔细查找了与StatusBar有关的代码，但是没有找到任何代码。“见鬼了？”苦思冥想之后，我想到如果要显示Hint的话，一定会有读取Hint的代码，于是又在整个项目中查找所有与Hint相关的代码，“Oh，My God！”，结果一样令人失望。
“怎么会出现这样的事？”我又找来几个编程浪子，向他们寻求帮助，最后我们得到一致的结论：既然StatusBar中显示Hint，那一定有代码操纵Hint与StatusBar，而且这种操作很可能在控件的MouseMove事件中。但经过检查却发现整个例子程序中没有一个处理MouseMove事件，而且有些控件根本就没有MouseMove事件（属性）。
当我正在苦苦搜索可能的其他原因时，一个浪子高喊“找到了！找到了！”，我赶紧中断搜索赶了过去。
“设置一个属性就可以搞定的”，
“什么属性？”，
“AutoHint。你看设置StatusBar的AutoHint属性为True，就可以自动地将控件的Hint显示在Panels[0]上了。”，
我照着他说的试了一下，果然如此。
终于，一个令我痛苦了一个下午的问题终于找到了罪魁祸首。
那个文件查找的界面也拷贝了下来，如下图所示。
这次捉妖的过程很有趣，不同于以前的错误调试，仅仅因为对于控件的属性不够熟悉就浪费了一个下午的时间。而且如果以前自己对这样比较特殊的属性进行记录的话，也许就会完全避免这种情况的出现了，因此我提醒读者们，在遇到比较特殊的属性、方法时，不妨把它们记下来。
