All works fine until you find yourself before the task to
have a dialog which allows selection of multiple files and folders in one go.
Often this is the case when it comes to batch processing. Of course, I have heard about tricks and tweaks like entering “File folder” or some stuff as the
filename before starting a dialog. I got sick and tired of it all.
Honestly this class did not
experience extensive testing, does not support selecting the nearest entry by
pressing a key (the leading character of the entry), nor is drag & drop
implemented. It might thus undergo minor changes in the future. The deal is
that I don’t want to follow up major postings about this, that and god knows
what. So, if you feel change is needed, go ahead and serve yourself. (Expect
plenty of source code in an unusual dense writing style). What it offers is usability
on several platforms since the dialog is a rewrite from scratch and rarely seen
simplicity. The Windows 7 Explorer and the Vista
FileOpenDialog where looked at
during development. Worst case you will deal a bit with assignments of known
but not under Windows 7.
Well it has a dialog functionality but only two items are
accessible before a call to
ShowDialog(). It is not visible in the designer
either (it does not contain components), so don’t put it in the toolbox. Not
much? No, it does not need more! Memory is assigned during the execution of the
dialog and released when exiting. Most properties and functions are declared
private. Lots of information is read out from the registry like: Places
previously visited, previous selections and associated data. The dialog will
not make any entries in the registry. Support for skins was not a requirement. Perhaps
the start folder (
initialPath) could be assigned as well. To save execution time
and memory only the folder level below the shown level is read to indicate
possible subfolders. This resembles lazy loading a bit.
Shown main folders Read subfolders
C:\ The root of c:\ only
D:\ The root of d:\ only
C:\Windows The fist level subfolders of c:\Windows
Be sure that OpenFileFolder.dll, shell32.dll version 5 and
above, and AnswerBox.dll from a previous article is in the directory of execution.
Ensure that shell.dll and OpenFileFolder.dll are entered in the project References
OpenFileFolder is internally makes use of answerbox.dll.
Coding, here we go:
OpenFileFolder off = new OpenFileFolder();
off.FilterComboBox.Items.Add("All files (*.*)");
off.FilterComboBox.Items.Add("Exe Files (*.exe)");
off.FilterComboBox.SelectedIndex = 0;
off.initialPath = @"D:\Icons\_BMP";
DialogResult z = off.ShowDialog();
string seletedItems = off.FileName;
That’s it already. If something was selected in the dialog, the
seletedItems will not be an empty string (
z is set to
DialogResult.OK and not null either.
In case multiple items have been selected,
show something like:
D:\\Icons\\_png\\3D (2).png;D:\\Icons\\_png\\3D (3).png;D:\\Icons\\_png\\3D (4).png
Arbitrate the information which is delimited with a semicolon
to get the individual selections.
The project is split up in two parts (two folders). The actual
development of the dialog is found in
OpenFileFolder. The whole development
took place in that folder. Tested code was then copied over into the files
OpenFileFolderClass. This might be a bit an unusual approach but guaranties
clear separation of targets and serves as a backup as well. In times of challenge,
a save heaven. Do not expect files to be identical in the two folders. The first
folder contains files which supports the Design Editor the files in the second
folder draw the whole GUI using code.
In the directory of execution:
- shell32.dll: Version 5 and above. Date >= 2009
- AnswerBox.dll: From a previous article
There is absolute no warranty what so ever implied or assumed. Use it at your own risk. It does a marvelous job for the author.
Copyrights and Trademarks shall belong to their respective owners. I am not going to fight over that!