很久以前我发现由于使用了Delphi Open File和/或Save File对话框，我在代码中遇到了访问冲突，这些对话框封装了Windows对话框。我在几个论坛上问了一些问题，我被告知这可能是由于某些程序为shell系统添加钩子导致DLL在每个进程中被注入的方式，其中一些可能会导致程序的破坏。为了记录，我使用的编程环境是在Windows XP 32位上运行的Delphi 6 Professional。
当时我没有使用Delphi的Dialog组件而是直接调用comdlg32.dll。这很好地解决了这个问题。
今天我第一次使用内存映射文件，果然，访问冲突开始出现在代码的奇怪部分。我尝试了我的comdlg32.dll直接调用，这次它没有帮助。为了将问题隔离为测试，我创建了一个列表框，其中包含我在测试期间使用的完全相同的文件。这些是我从“打开文件”对话框中选择的完全相同的测试文件，然后启动我的内存映射文件。我进行了设置，以便通过单击列表框中的文件，我将在我的内存映射文件测试中使用该文件，而不是调用comdlg32.dll对话框函数来选择测试文件。
再次，访问中提琴消失了。为了向您展示修复它是多么引人注目，我从1到3次试验中遇到访问冲突，到根本没有。不幸的是，当我需要使用文件对话框时，它会在以后咬我。
是否还有其他人处理过这个问题并找到了真正的罪魁祸首？你有没有找到我可以用来解决这个问题的解决方案，而不是像我现在一样在它周围跳舞？
提前致谢。
答案 0 :(得分：5)
我不明白如果你直接调用 COMDLG32.DLL ，如何不使用Delphi对话框组件来避免shell扩展DLL在你的程序中造成破坏。您仍在使用常用对话框，并且仍在注入这些shell扩展。
更有可能的是，不使用组件会在代码中产生副作用，这会影响或掩盖底层问题，将其降低到似乎已经解决的程度。
我怀疑这也是如此。
我不知道你的系统上安装了什么类型的hokey shell扩展 - 也许你有一些奇怪的扩展导致了一些问题。我只能说，在使用Delphi进行15年多的Win32编程时，我已经从未知道甚至听说过Delphi公共文件对话框组件来负责这种行为。
测试这个的一个简单方法当然是采用在你的机器上展示访问冲突的编译EXE，并在其他一些“洁净室”XP机器上运行相同的EXE，即没有第三方shell扩展安装了什么。
如果AV消失，那么您可以更加确信问题与shell扩展有关。然后通过逐个安装已知的外壳扩展到测试机上，直到AV重新出现，你可以隔离罪魁祸首并决定该怎么办...如果你的用户/客户不太可能然后，您可以选择将其列为已知的兼容性问题，然后继续讨论其他问题。
如果AV没有消失，那么你几乎可以排除Delphi对话框或任何shell扩展，因为它们在某种程度上是负责任的。
更一般地说，如果可能的话，查看AV正在发生的代码将是最有帮助的。
<强>附录：
我找到了this reference to AV's occuring with the Common Dialog components themselves。虽然这不会被视为AV的“一个奇怪的地方”，但它似乎在对话框组件本身内始终可重复。但无论如何我想我会提到它。如果不确切知道AV的发生位置，可能与此有关。