The Visual Basic TextBox control doesn’t directly support a lot of the features you need. The RichTextBox control is better, but it’s still a text box, not an editor. If you want to find and replace text or load a file using the common dialog, you’ll need to write your own code. You can find some sample editing code in the MDINote program that is supplied as an example with Visual Basic. The problem with this sample editing code is that it’s designed to illustrate MDI programming, not editing. You could reuse parts of the program by cutting, pasting, and modifying, but you’d soon find yourself doing more modifying than pasting.
What you want is the TextBox control, but with more methods and properties. Wouldn’t it be nice, for instance, if the TextBox control had an Undo method? Wouldn’t it be nice to simply specify a filename and see the TextBox control instantly fill with the file text? It would also be handy to have a FileOpen method that uses the Open common dialog to load a file into the text box and a FileSave method to save the modified contents to a file.
Let’s see now… while you have the menu open, you might as well order a few more features. How about SearchFind, SearchFindNext, and SearchReplace methods? Let’s use OptionFont and OptionColor methods to set the font and the color of text, using the appropriate common dialogs. Why not have a FilePrint method? Many editors have a status bar that displays information about file size and current positions, so you’ll want Line, Column, and Character. And, of course, you’ll want an OverWrite property to control insert and overwrite modes.
Vendors, Users, and Clients
To avoid confusion when discussing who uses your code, let’s define some terms. You, the designer and programmer of the Editor control, are the vendor. The programmers who use the control are your clients. The people who use programs created with the control are users. Users are the customers of your clients. Your responsibility to clients is direct; your responsibility to users is indirect.
Forget for the moment that, in many cases, the vendor, the client, and the user will be the same person—you. You’ll write better code if you pretend that thousands of clients will buy your control from computer magazines, software stores, and the World Wide Web, and that hundreds of thousands of users will buy programs built with the control. If the users don’t like the programs, they won’t call you; they’ll call your clients. Then the clients will call you.
You have two goals: making it easy for clients to satisfy users and making clients happy. You make it easy for clients to satisfy users by providing the features users want in their editors and viewers. You make clients happy if they can install these editing features easily. For example, clients will be very happy if they can get standard editing features by simply adding one statement to every edit-related menu, key, or button event. They’ll be happier still if they can add unusual or customized editing features with a little more work.
If you had all these features, creating an editor would be a matter of creating the menus, toolbars, buttons, and keystrokes necessary for the editor’s user interface and then tying each of these to the appropriate methods and properties. That’s what the XEditor control presented in this chapter does. It packs into one interface just about all the functionality a TextBox or RichTextBox control could possibly have.
The XEditor control is a handy tool that you could use in your projects either as is or with enhancements. More important, however, I will use it in the following sections to explain and illustrate techniques for writing truly reusable components.