I liked the way I implemented dialog boxes in D-Flat++. You derive a class from the DialogBox class and embed control objects in it. That's all it takes. The reason that Windows developers needed resource compilers was that the code to implement a dialog box or a menu does not resemble the output, structurally or any other way. It involved a bunch of function calls. The tabular format of the resource-compiler languages was an improvement because it gave mnemonic representation to the design. D-Flat++ substitutes a class design for a resource language, and loses none of the notational convenience in the process. It worked so well, that I used the same approach for the ToolBar and ToolButton classes. You derive your tool bar class from the base ToolBar class and embed ToolButton objects in it. Then you embed an object of the derived tool bar class in your derived application class. That worked so well, that I went back to the way that the menu bar is implemented and changed it to use the same approach.

It doesn't matter how well something is working, we can always find a reason to fix it.

This month I'll show you the new example application that demonstrates the D-Flat++ class library. It's a simple text editor called TED. It has a menu bar, a status bar, and a tool bar, and it lets you work on one text file at a time. After discussing TED, I'll look at how the tool bar and buttons work.

The design of a complex class library from the ground up tends to topple conventional wisdom. Just when you think that you have a mature, working class, one whose details you can tuck away and forget about in true black-box engineering style, it comes back to haunt you. Why? Because you try to derive a new class from it, that's why. Nothing humbles a class designer more than the realization that some old and trusted class can't live up to its promise because it doesn't host a particular newly derived class with grace and hospitality. The notion that C++ and object-oriented design promote reusable software any more than traditional procedural design is a mistaken one. C++ encourages such design, to be sure, because the class structure holds the key to encapsulation. But designs are made to be modified, and the notion that you can do it once, top down, bottom up, upside down, or any other way, and chisel the details in stone never to be budged again is a flawed one.

Case in point: I have this handy PushButton class in D-Flat++. It derives from a base Button class that handles all the details common to all control buttons--whether they're enabled, current setting, when it gets pushed, and so on. The PushButton class implements the command button. When the user pushes it--releases it, actually--the class calls a function in the program's application class. The PushButton class has all the stuff that it needs to watch the keyboard and the mouse while the user holds the key or button down and moves it around--everything that a well-behaved push button has to do.

Buttons on a tool bar work just like push buttons except that they have a different look and are grouped on the tool bar instead of coexisting with other unrelated push buttons on a dialog box. Just perfect for inheritance. Most of the details are the same, and only two areas need to be customized. So I did it; I derived the ToolButton class from the PushButton class. And it works now. The trouble was, however, that there were a lot of details in the PushButton's member functions that should be inherited and some others that should be customized. What's that, you say? Why is that a problem? Isn't that exactly what polymorphism is all about? Yep. Except that those reasonable and replaceable implementation details were usually tucked together in the same PushButton member functions. You can't polymorphize part of a function and inherit the rest. Its all one way or the other. The pure object-oriented designer would have gritted the old choppers and overridden all those virtual functions. Not me. I know all about those details in that base class. I designed and built it. If they were coded differently--better--it would be easier to inherit their good stuff and ignore the parts that I don't need in the new class. So I just waded in and changed it.

That's a difficult problem to avoid because you can't always know in advance which classes are going to become base classes and what parts of them will be inherited and overridden. I haven't yet figured a way to look at class during design and spot all the functionally independent implementation details. I think that it takes a while to develop that eye, and I haven't seen any class designs yet that evince that kind of designer foresight.

D-Flat++ is still preliminary but far closer to a working version than the first two. I am writing this column in September and will soon upload version 3. The first version was incomplete, but there was enough of an implementation to give you an idea of how DF++ works and how it differs from D-Flat. The second version had enough functionality to build an application, and the third one improves on that although there are more features to come. Later versions will be released by the time you read this. The C D-Flat function library is still available, too. You can download DF and DF++ from the CompuServe DDJ Forum or from M&T Online. You can also get them by sending a stamped, self-addressed diskette mailer and a formatted diskette to me at Dr. Dobb's Journal, 411 Borel Avenue, San Mateo, CA 94402. The software is free, but if you wish, include a dollar for my Careware charity, the Brevard County Food Bank.

In August, I attended Miller Freeman's East Coast edition of Software Development '93 in Boston. The show grows every year. I conducted a workshop on C++ object-database management based on the contents of my C++ Database Development (MIS Press, 1993).

End of self-serving plug--it's the Pournellian imperative rearing its ugly mug again. The point of all this is that as I was stepping through the overhead slides and holding forth on the code in that book, I kept tripping over how much easier everything I was describing would have been if the C++ compilers had included templates a year ago when I wrote it. I would explain some complex and contrived base class that lets programmers wedge their designs into the parts and pieces of the database manager, and I could see as I spoke that there is a far better way. Using inheritance to add management to objects of a class is cumbersome, but it used to be the only way to do it. Inheritance should be used to add and inherit behavior. Templates should be used to wrap a management function around objects. I'm going to have to do a second edition.

Another bonus of that seminar was an entertaining demonstration of Windows multimedia by Charles Petzold, the Windows programming guru who wrote the definitive book on the subject.

With a few simple demonstrations, Charles unlocked the MIDI puzzle that I posed a few months back. I came home and downloaded some of Charles's C programs from ZiffNet, and the shrouds of mystery fell away.

Charles demonstrated some impressive video and sound on a lunch box portable. He showed how the "not" could be removed from Nixon's "I am not a crook" quote by a simple swipe (pun intended) of the mouse. Then he ran an animation of Bill Gates's head on Ronald Reagan's body dancing to Mozart. He didn't pick on any Democrats. Maybe Mozart was a Democrat.

Fired up by Charles, I came home and got into MIDI again. Don Menza, a fine bebop tenor saxophone player had given me a transcription of Bill Clinton's saxophone solo on "Your Mama Don't Dance and Your Daddy Don't Rock 'n' Roll." Clinton played that at an inaugural party, sitting in with the band. I encoded the transcribed solo into a MIDI file and added electric piano accompaniment so a listener could find the context of the improvised solo. You can hear it yourself if you have a sound board and MIDI sequencer software. It's in the MIDI forum on CompuServe under the name CLNTON.ZIP.

After listening to the clip a few times, I decided to send it to Philippe Kahn. There's an open chair in the Turbo Jazz sax section after a Symantec defection, and I figure Bill might be looking for a gig in about three years.

Copyright © 1993, Dr. Dobb's Journal