If you look in the Windows API documentation, you’ll find that the common dialog DLL (COMDLG32.DLL) contains Find and Replace dialog boxes, which are called with the FindText and ReplaceText functions. These dialog boxes look a lot like those in Notepad and Write. But you won’t see hide nor hair of these functions in the CommonDialog control or in the Dialog Automation Objects.
Is this a conspiracy to make you write your own dialog forms instead of using the ones Windows provides? As a hardcore programmer, you don’t have to take this lying down. What’s to stop you from implementing VBFindText and VB-ReplaceText functions that wrap the internal API functions? Well, I wasted three or four days trying to prove that nothing could stop me, and I’m not one to give up easily. But eventually I did stop. Here’s why.
The Find and Replace dialog boxes are different from all the other common dialogs in one important way: they’re modeless. Once you pop them up on the screen, you can go back to your editor and keep working. The dialog box sticks around until you specifically close it. For a modeless dialog box to communicate with the editor window, the application must handle keyboard messages in its main window loop. In “Sending and Receiving Messages” in Chapter 6, I talked about message loops and why Visual Basic programmers don’t usually have to worry about them. But in the case of the Find and Replace dialog boxes, you do want to get into the main message loop and handle certain keyboard events, such as those involving the Tab and Enter keys.
You don’t need to hear the details of how I wasted time trying to capture keyboard events in a DLL hook procedure or with a message control. Suffice it to say that I pulled out every trick in this book, and none of them worked. I could display the dialog boxes on the screen. I could read text and settings from them. The mouse worked fine. But I couldn’t get the Tab and Enter keys to work.
If you want to try this yourself, you’ll probably suffer some of the same frustrations I encountered, and possibly some new ones. Or maybe you’ll find the solution. But before you start down that road, consider the alternatives.
If you try 20 different editors and word processors, you’re likely to encounter 20 different kinds of Find and Replace dialog boxes. The standard Find and Replace dialog boxes aren’t very popular with Windows programmers; everyone seems to have a different idea about how to find strings. Some applications have modal dialog boxes (Visual Basic version 3); others have modeless dialog boxes (Visual Basic versions 4 and 5). There’s something to be said for both approaches. You’ll also see a lot of variations in button names, available features, and the way certain features work. If you roll your own, you choose the features; if you use the standard dialog boxes, Windows chooses.
Remember that, in this chapter, you’re writing a library module for others. Your goal is to make it easy for your clients to offer their users whatever the clients think is most appropriate. But, of course, you must also try to judge the needs of the end users. In designing a library, as in designing an application, you have to make compromises. Ideally, you’d like to offer clients the ability to pass arguments that would specify whatever kind of Find and Replace dialog boxes they want to use. Realistically, if you try to offer every variation ever seen in a text editor, you’ll never finish.
A reasonable compromise is to design Find and Replace dialog boxes that you like, but also to provide low-level search functions so that clients can design their own dialog boxes or other user interfaces, but use XEditor properties and methods to do the actual searching.