We Keep Coding

C# WPF FolderBrowserDialog - Unable to retrieve the root folder

I am using the FolderBrowserDialog to select the Folder where user can save file. While opening the folder browse dialog, application get crashed and raised below exception.
System.InvalidOperationException: Unable to retrieve the root folder.
at System.Windows.Forms.FolderBrowserDialog.RunDialog(IntPtr hWndOwner)
at System.Windows.Forms.CommonDialog.ShowDialog(IWin32Window owner)
at TestApp.GenerateExcelReport()
Users are using the applications from cloud as My application is launched on Citrix Environment. Hence not all the users has facing this issue but few of them are facing.
string folderPath = "X:\\Reports";
if (!Directory.Exists(folderPath))
{
Directory.CreateDirectory(folderPath);
}
FolderBrowserDialog folderDialog = new FolderBrowserDialog();
folderDialog.ShowNewFolderButton = true;
folderDialog.SelectedPath = folderPath;
DialogResult dialogResult = folderDialog.ShowDialog();
if (dialogResult == DialogResult.OK)
{
folderPath = folderDialog.SelectedPath;
}
else
{
return;
}
Kindly suggest what can be the root cause of getting this issue while showing the FolderBrowseDialog. Also, suggest the potential fixes to prevent this exception.
Thanks & Regards,
Hiren Lad

This occurs for me when the folder %USERPROFILE%\Desktop doesn't exist. Creating that folder resolved the issue. Note that File Explorer may show a Desktop folder in %USERPROFILE% even if Desktop doesn't actually exist. You can verify whether Desktop exists by running dir %USERPROFILE% in cmd.

I'm late but the fix for this issue might be if you set the RootFolder property of FolderBrowserDialog other than the default RootFolder.
e.g
FolderBrowserDialog folderDialog = new FolderBrowserDialog();
folderDialog.RootFolder = Environment.SpecialFolder.MyComputer;

Openfiledialog works fine on windows 10, but freezes windows app on windows 7

I have windows application, where my program have the following code:
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
}
}
Now, on the MainForm(), I have few buttons, where upon clicking each of the button, I hide the MainForm and open a new form (Windows Form) using opendialog as shown in the below code:
this.Hide();
TestCenter testCenter = new TestCenter();
testCenter.ShowDialog();
this.Show();
Now, in the TestCenter form, I have a functionality (OpenFileDialog) for selecting a file, as shown in the below code:
OpenFileDialog ofd = new OpenFileDialog();
ofd.Filter = "image file |*.jpg;*.png;*.gif";
DialogResult dr = ofd.ShowDialog();
if (dr == DialogResult.Cancel)
return;
pictureBox_PartImage.Image = Image.FromFile(ofd.FileName);
txt_ImagePath.Text = ofd.FileName;
I have a TextBox and a PictureBox, for showing the filepath and the image after making the selection in OpenFileDialog.
The weird thing is, that, when I run this program from Visual Studio or from the installed programs on my laptop (Windows 10) it is working excellently without any issue.
But when I install this on client machine (Windows 7) it is freezing this Windows Form application when I click on the button which calls this OpenFileDialog().
Can someone please help me with this issue?
--------EDIT--------2/7/18--------
private void btnImage_Click(object sender, EventArgs e)
{
OpenFileDialog ofd = new OpenFileDialog();
// ofd.ShowHelp = true;
ofd.Filter = "Image Files (*.png, *.gif, *.jpg)|*.png; *.gif*;*.jpg";
DialogResult dr = ofd.ShowDialog();
if (dr == DialogResult.Cancel)
return;
pictureBox_PartImage.Image = Image.FromFile(ofd.FileName);
txt_ImagePath.Text = ofd.FileName;
}

I don't think your code is the problem. I suspect it is an installation issue. Make sure this program works first:
using System;
using System.Windows.Forms;
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
OpenFileDialog dlg = new OpenFileDialog();
dlg.ShowDialog();
}
}
Make sure you have installed the correct version of the .NET runtime that you are targetting.
The OpenFileDialog will load shell extensions into your application, if the client machine has strange shell extensions installed then it could interfere with your application.

Debug the program on the Windows 7 machine to narrow to exact issue.
Compile the program with debug symbols
Install remote debugging on the Windows 7 machine
Start the your program on the Windows 7 machine
Use Visual Studio on your developer machine to connect to the Windows
7 machine
Put a break point on the button to halt the code
Debug Interactively to see what call exactly is hanging
Troubleshoot further from there, you'll have more information. I've seen this before when I was building for ANYCPU. Try x86 for testing.

Apparently, adding OLE DB Services = -1 to my Connection String solved the issue.
In my form, I am using Access DB Connection for fetching data from the database. And this is the one that is messing up with loading of OpenFileDialog. And, this also explains why the sample code (by Wyck) is working fine (since there was no usage of DB Connection in there).
And I'm wondering why the answer by Vikas4u for this question (which was my reference) was voted down.

opening a file browser which has no access to the local drive C in C#

var dlgs = new System.Windows.Forms.OpenFileDialog();
dlgs.CustomPlaces.Clear();
var ListDrives = DriveInfo.GetDrives();
foreach (DriveInfo Drive in ListDrives)
{
if ((Drive.DriveType == DriveType.Fixed) && (Drive.Name != "C"))
{
dlgs.CustomPlaces.Add(Drive.Name);
}
dlgs.ShowDialog();
}
I am trying to open a file browser that should not have access to the local drive C so the user can select folders are files from rest of the local Drives like ("D" , "E").

I'm just looking at the OpenFileDialogue class documentation now, but I don't see anything that would restrict the user to certain drives... This post makes me curious as to whether or not it could actually be done; but perhaps it could be accomplished using a filter...

It's not possible to restrict where the user can access in the dialog itself (unless you implement your own dialog).
It's however possible to restrict whether the file can be opened (whether pressing the Open button or double-clicking will actually close the dialog), using the FileOk event.
Something like:
void DialogFileOk(object sender, CancelEventArgs e)
{
var dialog = sender as OpenFileDialog;
if(dialog == null) return;
if(Path.GetPathRoot(dialog.FileName) == #"C:\")
{
e.Cancel = true;
// maybe show messagebox or task dialog informing the user?
}
}
Again, this won't prevent users browsing the C:\ drive, it only prevents the dialog from selecting a file in that drive.
PS: adapt for multi-selection if needed.

How can I display a FolderBrowserDialog in LINQPad?

I want to browse for a folder in a LINQPad script so I tried using FolderBrowserDialog. It didn't work.
Here is a snippet showing what I'm doing?
string path = "";
var browser = new FolderBrowserDialog { ShowNewFolderButton = false };
if (browser.ShowDialog() == DialogResult.OK)
{
path = browser.SelectedPath;
}
This runs and hangs on the line with ShowDialog() with the yellow execution pointer against that line, but the folder browser dialog isn't visible.
I know that there is an overload for ShowDialog() that takes an IWin32Window owner argument and thought that might be the solution, but haven't yet figured out how to get an IWin32Window for the main LINQPad window. I hoped the Util class might provide a way but unless I'm missing it, it doesn't seem to.
Anyone have advice on getting around this problem?

Not solution, but an alternative, the FilePicker controle (part of new LinqPad Input Controls).
you can write:
new FilePicker().Dump().TextInput += (x, e) => ((FilePicker)x).Text.Dump();
or:
var picker = new FilePicker();
picker.TextInput += (x, e) => {
var fileName = picker.Text;
//action with the file...
};
full example:
void Main()
{
new FilePicker().Dump().TextInput += (x, e) => procces(((FilePicker)x).Text);
}
void procces(string file)
{
file.Dump("chosen file...");
//...
}

Setting the Run each query in its own process option to true is the cause of the problem. Setting that option back to the default false allows the code described above to run as expected.
However, making this change disables the built-in debugging. Furthermore the behaviour is still slightly problematic.
On first running the script the dialog is displayed and the script runs to completion after Ok or Cancel is selected. However, on running the script a second time it hangs as described in the question. After cancelling the execution and running it again the dialog displays but on the time after that it hangs again, and so on.
It was pointed out that setting the Always use fresh application domains option may resolve this and it does, allowing the dialog to display on every execution of the script.

I just came across this problem with LINQPad 5. I needed a folder picker similar to the file picker. Your solution worked without me having to modify LINQPad5 settings. The problem was the dialog was staying in the background. So here's how I got your snippet to work with that dialog in focus. Instead of using the FolderBrowseDialog.ShowDialog() I used the overload that passes in a windows form. I created a new form with description and window position then passed that to ShowDialog. That allowed me to set the description and window positioning.
string path = "";
using ( var browser = new System.Windows.Forms.FolderBrowserDialog { ShowNewFolderButton = false })
{
browser.Description = "Select Folder For Foo Processing";
var form = new System.Windows.Forms.Form(){TopMost = true, TopLevel = true};
var result = browser.ShowDialog(form);
if (result == System.Windows.Forms.DialogResult.OK)
{
path = browser.SelectedPath;
}
}
path.Dump();
I tried to initialize the form in ShowDialog with the settings, but had problems so I opted to declare it before show dialog. Hope this helps anyone with this problem.

Clicking a button on a windows from from a webform

I have created a windows form program that does some Business Intelligence but have subsequently needed to access this via a webform. I am fairly new to programming so I don't know what can be achieved here. But essentially I am wanting someone to go on to the net and when the user presses a button it sends a message to the windows form executable in a file and tells it to run and then press a button on the form, which runs a method to generate images of graphs. Is this possible?
Here is the relevant code.
In the webform I have this button.
protected void rolloutSmartSheets(object sender, EventArgs e)
{
string message = string.Format("Starting processes");
ltMessage.Text = message;
Process process = new Process();
process.StartInfo.FileName = #"P:\Visual Studio 2013\Projects\Smartsheet\SmartsheetAPI\obj\Debug\SmartSheetAPI.exe";
process.Start();
message = string.Format("Ended all processes");
ltMessage.Text = message;
}
That runs the executable but it opens the windows form and I imagine if the executable is sitting on another computer wouldn't that open on that computer? In which case i want it to tell it to press this button on the windows form which runs the method I need and then the user doesn't need to worry about it.
public void commitToDatabase_Click(object sender, EventArgs e)
{
commitToDataBase();
}

If you are able to have the clients install something in advance, you can provide this functionality using a custom protocol handler.
Example protocol handler from MSDN Article
HKEY_CLASSES_ROOT
alert
(Default) = "URL:Alert Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "alert.exe,1"
shell
open
command
(Default) = "C:\Program Files\Alert\alert.exe" "%1"
Then add a link onto your webform like this
href="alert://test"
As long as the client has the handler installed, both in the registry and the executable file, it will run C:\Program Files\Alert\alert.exe, passing "test" to it as the first paramater.
You can easily change this to provide the ability to run the local graph generator, and pass any parameters from the webform you might need.