1

很久以前，我发现由于使用了封装了 Windows 对话框的 Delphi 打开文件和/或保存文件对话框，我的代码中出现了访问冲突。我在几个论坛上问了一些问题，并被告知这可能是由于某些程序向 shell 系统添加挂钩的方式导致 DLL 被注入每个进程，其中一些可能会对程序造成严重破坏。作为记录，我使用的编程环境是运行在 32 位 Windows XP 上的 Delphi 6 Professional。

当时我通过不使用 Delphi 的 Dialog 组件而是直接调用 comdlg32.dll 来解决它。这很好地解决了这个问题。

今天我第一次使用内存映射文件，果然，访问冲突开始出现在代码的奇怪部分。我尝试了我的 comdlg32.dll 直接调用，但这次没有帮助。为了将问题隔离为测试，我创建了一个列表框，其中包含我在测试期间使用的完全相同的文件。这些是我从打开文件对话框中选择然后启动我的内存映射文件的完全相同的测试文件。我进行了设置，以便通过单击列表框中的文件，我将在内存映射文件测试中使用该文件，而不是调用 comdlg32.dll 对话框函数来选择测试文件。

再次，访问违规消失了。为了向您展示我在 1 到 3 次试验中遇到访问冲突到根本没有遇到访问冲突，这是多么戏剧性的修复。不幸的是，当我确实需要使用文件对话框时，它当然会在以后咬我。

有没有其他人也处理过这个问题并找到了真正的罪魁祸首？你们有没有找到我可以用来解决这个问题的解决方案，而不是像现在这样绕着它跳舞？

提前致谢。

4

1 回答 1

5

如果您随后直接调用COMDLG32.DLL，我不明白不使用 Delphi 对话框组件如何避免 shell 扩展 DLL 在您的程序中造成严重破坏。您仍在使用通用对话框，并且仍在注入这些 shell 扩展。

更有可能的是，不使用组件会在您的代码中产生副作用，从而混淆或掩盖潜在问题，将其减轻到似乎已解决的程度。

我怀疑这里也是如此。

我不知道你在系统上安装了什么样的 hokey shell 扩展——也许你有一些奇怪的扩展会导致一些问题。我只能说，在使用 Delphi 进行 Win32 编程的 15 多年中，我从未知道甚至听说过 Delphi 通用文件对话框组件负责这种行为。

一个简单的测试方法当然是获取在您的机器上显示访问冲突的已编译 EXE，并在其他一些“洁净室”XP 机器上运行相同的 EXE，即没有安装第 3 方 shell 扩展什么-如此。

如果 AV 消失了，那么您可以更加确信问题与 shell 扩展有关。然后通过将已知的 shell 扩展一个接一个地安装到测试机器上，直到 AV 重新出现，您可以隔离罪魁祸首并决定如何处理它......如果它是您的用户/客户不太可能是的使用 then 您可能会选择简单地将其列为已知的兼容性问题并继续处理其他问题。

但是，如果 AV 没有消失，那么您几乎可以排除 Delphi 对话框或任何 shell 扩展以某种方式负责。

更一般地说，如果可能的话，查看发生 AV 的代码将是最有帮助的。

附录：

我确实发现这种对 AV 的引用与 Common Dialog 组件本身一起发生。虽然这对于 AV 来说不算是“一个奇怪的地方”，但在对话组件本身内，它似乎是始终可重现的。但我想我还是会提到它。在不确切知道您的 AV 发生的位置的情况下，这可能是相关的。

于 2010-03-17T23:23:00.760 回答