saveFileDialog 长时间等待“确定”确认
我正在使用 C# 在 Visual Studio 2008 中编写（如果这有什么不同的话），并且我有以下代码片段：
if(saveFileDialog1.ShowDialog() == DialogResult.OK)
{
//Write Stuff to File Here
}
有一段时间我认为编写文件的代码要花很长时间，但是在调试时似乎要花很长时间（ 5 到 10 秒）只是为了在“if”语句和“if”内第一个代码的第一个括号之间步进。
我做错了什么吗？在 UI 中创建 saveFileDialog 对象与动态创建它（通过代码）之间有什么区别吗？如果没有“else”语句会有什么不同吗？
任何想法或想法将不胜感激！
I'm writing in Visual Studio 2008 using C# (if that makes a difference) and I have the following snippet of code:
if(saveFileDialog1.ShowDialog() == DialogResult.OK)
{
//Write Stuff to File Here
}
For a while I thought my code that wrote the file was taking forever, however upon debugging it seems to take forever (5 to 10 seconds) just to step between the "if" statement and the first bracket of first code within the "if".
Is there anything I'm doing wrong? Is there any difference between creating the saveFileDialog object in the UI versus creating it on the fly (through code)? Would it make a difference if there is no "else" statement?
Any thoughts or ideas would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这并不罕见，在许多机器上，当您使用该对话框时，大量 DLL 会加载到您的进程中。您可以通过使用“项目+属性”、“调试”选项卡来查看它们的加载情况，勾选“启用非托管代码调试”复选框。 “输出”窗口显示了每个蠕虫进入您的程序的 DLL 的踪迹。
这些是 shell 扩展、Explorer 的定制。您使用的对话框是外壳对话框，您肯定认识到与常规资源管理器视图的相似之处。图标和上下文菜单之类的行为是相同的。在开发人员的计算机上安装大量 shell 扩展很常见，比用户计算机更常见。它们有很多，提供诸如将您喜欢使用的任何工具与资源管理器本身集成等便利。
调试问题并不那么容易，您不会拥有这些扩展的实际源代码。您可能会从“输出”窗口中的跟踪中得到有关麻烦制造者的提示。如果在某个特定 DLL 之后出现长时间暂停，则很有可能该 DLL 就是问题的根源。但没有什么真正坚实的。
更好的方法是使用 SysInternals 的 AutoRuns 实用程序。它会准确地向您显示安装了哪些 shell 扩展，并允许您通过单击复选框来禁用它们。开始禁用任何没有 Microsoft 版权的内容以及您可能没有的内容。需要注销+登录才能使更改生效。
This is not unusual, on many machines a ton of DLLs get loaded into your process when you use that dialog. You can see them getting loaded by using Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" checkbox. The Output window shows a trace of every DLL that worms its way into your program.
These are shell extensions, customizations for Explorer. The dialog you use is a shell dialog, you surely recognize the similarity with regular Explorer views. Things like icons and context menus behave the same. Having a lot of shell extensions installed is common on developer's machines, more so than user machines. There are a lot of them out there, offering such conveniences as integrating whatever tool you like to use with Explorer itself.
Debugging the problem isn't that easy, you won't have the actual source code for these extensions. You might get a hint about the troublemaker from the trace in the Output window. If there's a lengthy pause after one particular DLL then odds are good that this DLL is the source of the problem. Nothing really solid though.
The better approach is to use SysInternals' AutoRuns utility. It shows you exactly what shell extensions are installed and allows you to disable them by simply clicking a checkbox. Start disabling anything that doesn't have a Microsoft copyright and stuff you could live without. Logout + Login required to make the changes effective.