I remember my amazement, back in the dark ages of Windows 1 and 2, when I learned that every programmer who wanted an Open dialog box had to write the code to fill the list box by reading the files out of the directory. The common dialog functions introduced in Windows 3 solved the problem for dialog boxes, but everyone still had to write their own toolbars, outlines, status bars, and what have you.
Somewhere during the time frame of Windows for Workgroups, the common controls DLL was created and used to implement the toolbars of File Manager. The source code for this DLL appeared as a sample in the Software Development Kit, and it later became available on the Microsoft Developer Network. COMMCTRL.DLL became a kind of standard, though not official. It was one of three toolbar implementations used by different groups at Microsoft. (You can see the differences if you study old Microsoft applications carefully.)
Microsoft didn’t necessarily start the industry trend toward toolbars, status bars, and property sheets, but it jumped on the bandwagon and eventually standardized most common controls by expanding the 16-bit COMMCTRL.DLL into COMCTL32.DLL. Visual Basic wrapped this C-specific DLL into the Microsoft Windows Common Controls—a single OCX file containing TreeView, ListView, ImageList, Toolbar, StatusBar, TabStrip, ProgressBar, and Slider. This version of Visual Basic introduces Microsoft Windows Common Controls 2 with Animation and UpDown controls. Perhaps we’ll soon see new controls providing the interface doodads introduced in Microsoft Internet Explorer.
Of course, rather than hold your breath, you could turn to other hardcore programmers for assistance. Ramon Guerrero and Andrea Wyss wrote components that wrap some of the coolest new interface gadgets. I’m not going to have a chance to explain these controls in the book, but they’re provided on the companion CD with samples and READMEs.
On the surface, the common controls, especially TreeView and ListView, seem to offer an easy way to create applications that look like Windows Explorer. Personally, I like the idea of Windows Explorer more than its implementation. I was looking forward to creating my own better explorer. My plan was to clone the real Explorer and then start adding features. I planned to name this application after one of my favorite explorers, Meriwether Lewis. Unfortunately, the attempt met with dismal failure in the first edition of this book and I ended up naming my pitiful explorer after Columbus, the man who never did reach the East by sailing west.
Well, I’m happy to say that Meriwether has been resurrected. It took some help from new Visual Basic features such native code and better access to interfaces. Also, I’ve learned a lot and spent more time on the problem. Figure 11-12 shows Meriwether at publication time. I might be able to get a better version on the companion CD. The current version isn’t full-featured, and the performance doesn’t quite match the Windows Explorer. But it’s a reasonably efficient program that you can enhance to create your own better explorer.
Figure 11-12. Meriwether explores the northwest.
Writing a real explorer program is a major task that I didn’t have time to finish or explain completely, but I will use Meriwether (and some other samples) to briefly examine common controls. The Visual Basic documentation explains normal use, so I’ll focus on some problems and workarounds you won’t find in the manual.