Introduction
If you have ever played with MS-DOS, you'll be familiar
with wildcard patterns. For example, to get a listing of all
text files in a particular directory, you would type dir
*.txt. The Windows Explorer doesn't let you do that.
I wrote Wildcard Select because I occasionally need to
select all HTML files from a folder to perform some
operation on them. In MS-DOS I could have specified the
wildcard pattern *.html to select these files,
but in Windows my only hope is to pick them by hand. You
can, of course, switch to the Details View, sort on the Type
column, and select all HTML files by dragging a box around
them, but that's not particularly convenient. Plus, it
doesn't work if you need to select files based on other
criteria than their extension, for example all GIF files
that begin with the prefix holiday. Using Wildcard
Select you would type holiday*.gif and be done
with it.
Wildcard Select is an Explorer shell extension, which means
that it lives in Explorer's right-click menu. If you right-click
on a file, folder, or the background of an Explorer window and
choose the Select... item from the menu, the following
dialog box pops up:
You can type the search pattern in the edit box. While
you are typing, Wildcard Select tells Explorer to select all
the files from the current window that match the pattern. If
you press Cancel or erase the pattern, Wildcard Select
restores the original selection, if any. If one or more
files were selected at the time you invoked
Wildcard Select, it will only try to match the items from
that selection.
In this article, I'd like to explain how Wildcard Select
works. It uses some COM and ATL, a little MFC, and messes
around with Windows Explorer. I won't be showing you any
code snippets (the article is long enough as it is already),
but I will give a detailed explanation of the program's
inner workings.
If you take a look at the source, you'll find that in
some places I'm using STL's string class and in
others I use C char arrays and functions such
as strrchr(). From time to time, I also use
MFC's CString. I prefer working with the STL
classes, but sometimes it just makes more sense to work with
the others. For example, if all the functions that use a
particular string expect a char array, then
it's a bit overkill to store that string as a
CString or STL string, just for
consistency's sake. I hope this doesn't make the source too
confusing...
The boring stuff
You can read all you ever wanted to know about shell
extensions in Michael Dunn's
The
Complete Idiot's Guide to Writing Shell
Extensions series, so I am not going to go into much
detail about writing the actual shell extension code. I'll
just give you a brief recap here. A shell extension is a COM
DLL. Instead of implementing all the COM logic itself,
Wildcard Select uses just enough ATL to get by. The files
that take care of this are
Select.idl,
CtxMenu.rgs, and
Select.cpp.
The Select.idl file describes
CtxMenu, which is our COM class, and
ICtxMenu, its interface. CtxMenu
doesn't really need an interface of its own, but IDL
requires us to specify one. Likewise, we specify a typelib,
but we don't use that either.
The CtxMenu.rgs file contains the registry
entries for our shell extension. These entries tell Explorer
that our shell extension must appear in the context menus
for all files, folders, and the background of Explorer
windows. It will not appear if you right-click on drive
names or special folders such as the Control Panel.
The Select.cpp file contains several boring
COM housekeeping functions. The
DllRegisterServer() and
DllUnregisterServer() functions register and
unregister the DLL, using the information from the RGS file.
Unlike a typical ATL application, we pass FALSE
as the parameter to _Module.RegisterServer().
This only puts the GUID for our COM class in the registry,
not the GUIDs for the ICtxMenu interface or the
typelib. We don't use those, so there's no point cluttering
up the registry.
Note that DllRegisterServer() and
DllUnregisterServer() are not called by
Explorer, but by the installer. If you downloaded the source
files instead of the installer, you will have to register
the DLL yourself using the command line tool
regsvr32. If you compile the source from within
Visual C++, then regsvr32 runs as part as the
build process.
Because Wildcard Select uses MFC to build its GUI,
Select.cpp also contains the
CSelectApp class, which extends from MFC's
CWinApp.
What did the user click on?
The interesting stuff happens in CtxMenu.h
and CtxMenu.cpp. These files contain the
declaration and implementation of the CtxMenu
class that we saw in the IDL file. CtxMenu is
the guts of Wildcard Select. Like all good context menu
shell extensions, it implements the
IShellExtInit and IContextMenu
interfaces.
In short, this is what happens: When the user right-clicks
inside an Explorer window, Explorer calls
CtxMenu's Initialize() function. At
this point, the context menu isn't visible yet. Explorer
then calls the QueryContextMenu() function to
add the Select... item to the menu, and shows
it. When the user moves over this menu item, Explorer
obtains a description from GetCommandString().
Finally, when the user picks the Select...
item, Explorer calls InvokeCommand().
The only place where we can figure out whether the user
clicked on a file or on the background of the window is in
Initialize(). This distinction is important: if
the user clicked on the background, then no files are
selected and Wildcard Select must try to match all files
against the wildcard pattern. On the other hand, if the user
clicked on a file, there is a selection and Wildcard Select
will only try to match the files from that selection.
The two functions that deal with this are
ClickedOnBackground() and
ClickedOnFileOrFolder(), respectively. In the
former case, we set the allFiles flag to
true. In the latter, we set it to
false, and copy the names of the selected files
into the selected list. In both cases, the
folder field receives the name of the current
folder.
Explorer's guts
Explorer calls the InvokeCommand() function
when the user picks the Select... item from the
context menu. This is where we pop up the dialog box and do
the funky stuff. The funky stuff, of course, is selecting
files in the Explorer window. But how do we do that? Well,
fifteen seconds with Spy++ will tell you that Explorer
simply uses a ListView control to display the filenames. And
to select items in a ListView, we simply send it a message.
Conveniently, InvokeCommand() receives the
HWND of the Explorer window. On my copies of
Windows 95, 98, NT4, and XP, this window contains a child
window with the class SHELLDLL_DefView, which
in turn contains a child window with a class named
SysListView32. This is the control we are
after. On Windows Me and 2000, however,
SHELLDLL_DefView contains not
SysListView32, but Internet
Explorer_Server, which in turn contains ATL
Shell Embedding. This last window finally contains
the SysListView32 that we need. Our
FindListView() method takes the handle of the
Explorer window, looks for SHELLDLL_DefView,
and then simply recurses through all
SHELLDLL_DefView's child windows until it finds
the SysListView32 we're after.
Now that we've successfully obtained a handle to
Explorer's ListView control, we show the dialog box. The
dialog box is handled by our PatternDlg class,
which is a fairly simple affair. Seen one, seen 'em all. We
pass a this pointer to its constructor, because
PatternDlg occasionally needs to call functions
from CtxMenu. Specifically, it calls
SelectFiles() whenever the user enters a
character, and RestoreOriginalSelection() when
the user erases the search pattern.
Selecting the files
Next up is the SelectFiles() function, which
really does all the work. Instead of writing my own wildcard
matching function, I decided to use the Win32 "find file"
API functions, since they already know how to deal with
wildcards. We need these functions anyway to read the
contents of the current folder. So we'll simply combine the
two by feeding the user's search pattern into
FindFirstFile(). Then we'll loop through all
the files it finds and tell Explorer's ListView to select
the corresponding items.
But what are the corresponding items? As it turns out, we
can't simply compare the filenames that we obtain from
FindFirstFile() and FindNextFile()
with the text from the list items, because
what is shown in the ListView may not be the actual
filename.
If the "Allow all uppercase filenames" option from
Windows is disabled, then the case of the filenames may
differ. For example, the corresponding list item for the
file called AUTOEXEC.BAT is
Autoexec.bat. If that was the only problem, we
could have performed a case-insensitive compare, but alas,
Windows also has a "hide file extensions for known file
types" option. With that option enabled, a filename like
cool.exe will show up as just
cool, without the extension. Finally, the find
functions will happily return hidden files, but your
Explorer windows may be setup not to show them.
Surely, there must be a way for Windows itself to know
which filename belongs to a particular list item? Well, I
took a guess here, and assumed that the lParam
member of a list item contains the PIDL to the file. (For
more about PIDLs and stuff, see Mike Dunn's article on namespace
extensions.) I was right - it must
have been my lucky day ;-) We don't really need to do
anything with that PIDL, except feed it to
SHGetPathFromIDList(), which in turn gives us
the path to the file that this list item represents. Nice,
eh. Now we can compare that to the actual filename. All this
magic happens in our GetListViewIndex()
function. It returns the index of the file in the ListView.
Actually, SHGetPathFromIDList() gives us
back the right filename, but the wrong path, always starting
from the desktop (at least during my tests). This probably
has something to do with relative and absolute PIDLs.
(Again, see Mike's article.) However, I couldn't care less.
We can simply ignore everything up to the filename; after
all, the find functions don't include the whole path either,
so we would have to strip it off anyway to do the
comparison.
The SelectListViewItem() function, finally,
takes the index that we obtained from
GetListViewIndex(), and uses the
ListView_SetItemState macro to send the message
to the ListView control. Notice that we set not only the
LVIS_SELECTED flag to select the item, but also
LVIS_FOCUSED to give it the focus. If we don't,
then the focus could end up on a file that is not selected,
which is rather awkward if you're using the keyboard to interact
with Explorer.
Other things
To provide as much feedback as possible, the selection is
being made while the user types. Unfortunately, the ListView
only shows the selected items if it has the focus. But
because the user is typing in a dialog box, the ListView
doesn't have the focus, and consequently doesn't show the
selection until after the user closes the dialog box. At
least, that's how things work on my Windows 98 machine. On
XP, it does show the selection, but in light gray, not
dark blue.
A quick glance at MSDN explains that the ListView has a
special style called LVS_SHOWSELALWAYS that is
responsible for this. Now it always shows the selection,
even if the control does not have the focus. On older
versions of Windows, Explorer doesn't set this style, even
though its ListViews support it. Therefore, just before we
show the dialog box, we set the
LVS_SHOWSELALWAYS flag in the ListView. And
would you believe it, now it does show the selection
while the user is typing. Of course, we restore the original
ListView style after the dialog box closes.
Being able to invoke Wildcard Select from the right-click
menu on a folder's background is convenient, but as Mike
Dunn remarks,
there is a usability
issue here. On all Windows versions prior to XP, the index
passed into IContextMenu's
QueryContextMenu() function is -1, which means
that the Select... item is added at the bottom
of the menu, below the Properties item. Out of habit, most
users will expect Properties to be the last item on the
menu, and will find it very confusing (and irritating) if we
were to put Select... at the bottom. So we'll
put it at the top instead. If index equals -1,
then we pretend it is 0. Is this bad? I don't know. It
seemed to work fine for me during testing... (By the way,
the right-click in the window background only works with
shell versions 4.71 or better.)
Because we compare the contents of the ListView with the
actual filenames, shortcuts are a bit of a problem. Explorer
doesn't show it, but the filenames of shortcuts actually end
with the extension .lnk. If you want to match a
shortcut, then your pattern should end with
.lnk as well... (Fortunately for us,
SHGetPathFromIDList() doesn't try to resolve
the shortcut, or we'd be in real trouble.)
The SelectFiles() function isn't
particularly smart. It contains several nested loops, and if
the current folder contains lots of files (say, more than
2000), Wildcard Select can be pretty slow. I plan to speed
it up somewhat in the future. Any suggestions are welcome!
Credits
Wildcard Select's dialog box uses two subclassed
controls: an auto-completing combo box and a hyperlink. Both
were loosely based on code written by Chris Maunder: Implementing
an autocompleting Combobox and
Hyperlink
control. I changed the code around a bit to fit this project;
if you want to
re-use these classes, you're probably better off with Chris'
original code instead. The shell extension code is based on
the samples from Michael Dunn's Complete
Idiot's Guide to Writing Shell Extensions articles.
What is new?
Version 1.0 gives an error message ("Cannot send message
to Explorer") when you invoke it from something other than
Explorer's list view. This happens, for example, if you
right-click inside the tree view of the Explorer window. Now
Wildcard Select cannot find the list view because this time
the InvokeCommand() function is not given the
HWND of Explorer's window, but the
HWND of some other window.
I spend some time writing code that first finds the
handle of the main Explorer window, instead of assuming that
we already have it. But then I realized that invoking
Wildcard Select from the tree view's right-click menu
doesn't make much sense. Even though a folder may be
selected in the tree view, that doesn't necessarily mean its
contents are visible on the right. And it doesn't make much
sense selecting files if you can't see them.
The simplest solution to this problem turned out to be:
don't add the Select... item to the context
menu unless it is invoked from Explorer's list view. We do
this in QueryContextMenu. First, we get the
HWND of the active window with
GetFocus. As it turns out, that is the
HWND of the list view, so that's easy. Then we
make sure that the window's class is called
SysListView32. If it's not, we simply bail out
and don't add our menu item.
