Home/ Questions/Q 7490117
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T15:33:11+00:00

I’m writing in Visual Studio 2008 using C# (if that makes a difference) and

  • 0

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0