Key Strokes, Keyless, and Key West

My friend Stan Trujillo is a fellow author of computer books. He and I coauthored two books on games programming last year. We spent many long hours banging out C++ code to encapsulate most of what a games programmer needs to do. We also discussed, at great length and in great depth, our respective notions about love, life, and philosophy. Our perspectives differ somewhat because of the generation gap that separates us. Stan is about half my age and younger than my youngest offspring.

Stan remarked recently about an interview that someone had with Paul Simon, the singer/songwriter. Simon says (really) that an artist's most creative work occurs in the artist's thirties. Stan wondered if that observation applied to programmers and programming writers, too. He worried that he had not yet reached his prime; and, when he did, he'd have only ten good creative years. I thought about Simon's observation and about why he would think that way. I did not wonder for an instant whether that opinion applies to programmers. It does not. Simon's talent for composition and solo performing circumscribes a musical form that was at its most popular when Simon was in his thirties. Naturally, he would think that those were his most productive years. He can, I am sure, still write songs that would have been popular then, but no one wants to hear them today. I understand and relate to that. My musically creative era passed in real time even before I passed through it in virtual time. My compositions and playing would have enjoyed their peak popularity (assuming that I would have performed, published, and been discovered) in my pre- and early teens. Not that I was able to do it then, but the kind of music that I prefer to play today was popular then. I don't know what I'll do when my following dies off.

Programming is quite different. It has no big-band (or Jimi Hendrix, or Chuck Berry, or BeeGees, or Jelly Roll Morton) era for older programmers to cling to. ("What do these kids today know?") We are all happy to be free of technology and programming models that limit us when new things come along. I know only a few diehards who insist on staying mired in old languages. Most programmers embrace innovation when it improves their ability to express algorithms, and that willingness knows no generational boundaries. And innovation will never stop, so you should continue to conceive and create good programs as long as you want to.

Stan writes high-tech books for Coriolis Books now. His latest book is called Cutting Edge Direct3D Programming, and it is about using the DirectX graphical extensions to display 3-D images in Windows programs. Stan dedicated the book to me, calling me the "wise and venerable Al Stevens." You could not get away with that if you were older than half my age.

Optima++ 1.5

Last month I reported my experiences with Borland's new C++Builder development system. My plans were to continue that discussion by porting last month's amortization schedule example program to another visual Windows development environment, Optima++ from Powersoft.

I installed Optima++ 1.5 on a COMPAQ Presario laptop, because I wanted to do this project from the road. I loaded up everything I needed and hit I-95. It's five and a half hours from my house to tourist Paradise. As I write, I am sitting in serene seclusion in a 36-foot motorhome at an RV camp just a few miles east of Key West. The stereo quietly renders vintage Miles Davis in the background. The sky is clear of clouds, interrupted every now and then only by an occasional pelican who circles and cruises tirelessly for seafood. The blue-green waters of the Gulf of Mexico are visible from my front and side windows, which are wide open; a steady early-March breeze makes air conditioning an unnecessary and unwanted luxury. A short walk to the beach reveals a view of both the Gulf and the Atlantic Ocean, their mutual majesties divided only by a frail-looking man-made bridge that connects the two lesser Keys preceding Key West on the traveler's route west. Judy is off somewhere on Duval Street browsing the endless souvenir shops, credit cards at the ready, happily seeking out colorful conch shells and Jimmy Buffet T-shirts. Hemingway's house is nearby, mute inspiration for all serious writers and drinkers who pass by. My temporary neighbors are mostly elderly retirees who camp here for the winter and stay to themselves. They don't associate with riff-raff, transients like me who don't have enough permanency to put down a few lawn statues and potted plants and a plastic picket fence around the site. No, they don't bother me much, for I'll soon be done and on my way. This is the perfect setting to experiment in solitude with a new programming environment -- the perfect setting, too, to yield to Hemingway's ghost, unleash the writer's muse, and tell you all about it.

Optima++ has a Visual Basic-like developer's interface quite similar to that of C++Builder. This is good. A natural tendency rises to compare the two products: Both have extensive database and Internet support. I have not explored the advanced features of either product because they are not my immediate concern. I am looking specifically at their ability to support C++ Win32 programming with intuitive application framework class libraries, visual development environments, and effective encapsulation of the GUI parts of the Win32 API. In other words, to get up the Windows curve with the least pain. There shall be no steep, painful curves here in the Keys.

My pal Al Williams gave Optima++ favorable mention in his "20/20" column in Dr. Dobb's Sourcebook (March/April 1997), and made me think that Optima++ might be another good way for C++ programmers to get into Windows programming without climbing the Windows API curve. My conclusions, however, are not as glowing as Al's. Why not? Because I had trouble getting Optima++ to run reliably.

Before I go further, you might wonder why I do not get online with Powersoft and solve this problem, whatever it is. For one thing, I do not have a cellular modem, and just now, cyberspace is about as far away from Key West as it can be. For another thing, I brought only two of the Optima++ manuals with me: Getting Started and the Programmer's Guide. Neither of these books has Powersoft's e-mail or snail-mail addresses, much less a support phone number. When you abandon the conveniences of a well-equipped office and lab for the freedom of the open road, you leave behind some of your cherished resources. There's never room for everything. I can't defer this experiment until I get home; the deadline for this column is too near, and I have to pay for all those conch shells and T-shirts. Consequently, you will have to make do with whatever progress I can report and trust my conclusions.

Here's what I did. I opened a new Optima++ project and saved the initial default one-form, VB-like, C++Builder-like project, giving it a new name with the Save As command. Then I opened the Object Inspector dialog to change some of the default form's characteristics: its name and title text, to start. Windows 95 abruptly reported that "Optima++ reported an unrecoverable error and [would] be shut down." This exception happened regularly and predictably.

I noticed that the Object Inspector does not behave appropriately when you change an object's name. I changed the default form's name from the boring Form1 that all these visual environments start with to the more descriptive name, DataEntry. The Object Inspector does not record the new name in the current display of its dropdown list of objects. The old name stays there even though no object with that name any longer exists. Maybe that's what causes the blowup. The same thing happens with control objects -- buttons, editboxes, and so on -- that you add to the form. When you double-click an object on the form, Optima++ opens a Properties window for that particular object that also lets you change the object's name, but the Object Inspector does not change its notion of the name -- confusing to the eye and maybe to the software too, which might be trying to dereference the properties of something that no longer exists.

By not doing exactly what I wanted to do in the precise order that I originally wanted to do it, I got past the point of the blowup, and Optima++ settled down. That's a relief, because I don't know where in the Keys I'd find something else to write about this month. There are subtle differences in Optima++'s programmer interface. For example, double-clicking a control on a form does not open the control's code window like it does with C++Builder and VB. Instead, to open the code window, you have to open the Object Inspector's Event page for the control, or right-click the control and choose the Event command. For another example, it's not real easy to figure out how to set a breakpoint. The Breakpoints command from the Run menu only displays the currently set breakpoints. A Help query revealed that pressing F9 toggles breakpoints in the code editor window.

Both Optima++ and C++Builder are less than intuitive when it comes to viewing parts of the construction interface. With both packages, I closed the form window to devote my attention to some code. When, with either program, I wanted to reopen the form window for some more construction, I couldn't find it. My intuition told me the form window should be part of the View menu, but it is not. Eventually, I found it. Oddly, both packages put the closed form window on the Window menu, which, under every Windows GUI convention I have ever seen, is used exclusively for windows that are currently open and in view either on the desktop, as a minimized icon, or as a Taskbar button. Nowhere else have I seen closed, hidden windows listed on the Window menu. Has a new convention crept in, unbeknownst to me? Or is one of these guys copying the mistakes of the other?

Because of the time I spent wrestling with the blowups, I did not have time to port the entire amortization program to Optima++. The project that you can download (see "Availability," page 3) lets you enter the loan principal, interest, and term in years. Then, when you click a button, the program computes and displays the payment. This experiment was enough to convince me that, the unusual bug notwithstanding, Optima++ is a solid development package that fulfills my objective of shielding programmers from the Win32 API while providing an intuitive visual development environment. In other words, a worthy competitor to C++Builder.

Optima++ 1.5 is a released product, not a beta like the C++Builder that gave me so much success last month. Surely Optima++ is, as I have concluded, a solid package, or the reports from Al Williams and others would have reflected otherwise. After getting over that first hump, I am impressed with how well Optima++ handled my requirements. I'm not sure what caused that initial problem, because it went away as mysteriously as it showed itself. Maybe I have a flaky release, and maybe the package is buggy with the installation options I chose, and maybe the Sun gods want me to put on flip-flops, shorts, and a T-shirt, get out of this motorhome, and go drink a margarita at Sloppy Joe's. I don't know. But I do know this: Although working fine now, Optima++ 1.5 did not work with 100 percent reliability when first installed on this particular laptop in this particular month from this particular mobile office right here in these particular Florida Keys. Pass another slice of Key lime pie, please.

Windows CE

I wrote the first two paragraphs of this column in less comfort than my current tropical location would suggest. The uncomfortable parts were my hands and eyes. My discomfort was due to the latest step forward in the evolution of computing. How's that again, you ask?

I like it when computers and operating systems get smaller and simpler instead of the other way around. Changes in programming complexity over the years resemble a sawtooth pattern. Early mainframes had no operating systems, programs were single-user and single-tasking, and programmers tested hands-on from the console. It didn't stay that way. Eventually, programming and operating mainframe computers became so complex that programmers were not allowed to see, much less operate, a computer. They couldn't trust us to have our hands on the machine. It was all done through a window. A real window. A hole in the wall. Card decks of JCL and source code were input and paper core dumps were output. With one-day turnaround, we could fix only one bug a day.

Then along came minicomputers. Single-everything, hands-on testing from the console. You had to install speed bumps in the mainframe programmer's shop to slow down the defections. However, as minicomputers became more powerful and more complex from a programmer's viewpoint, things got harder again. VAXes, and one thing, and then another. Up the sawtooth.

Next, we got microcomputers with programming models that recapitulated earlier evolutions, growing from extreme simplicity in the beginning to dazzling complexity today. If you don't think so, compare the TRS-80's Basic interpreter with ActiveX. Well, at least we still get to perform hands-on testing.

The next logical step down the sawtooth is Windows CE -- the operating system from Microsoft developed to run today on hand-held palmtop computers and eventually as the embedded system OS of choice. Or so Microsoft would have it.

Last week I attended the Visual C++ developers conference in Orlando, Florida, sponsored by TPD and Microsoft. The emphasis was on ActiveX and the ActiveX Template Library (ATL). I can't report much on that because I couldn't get into those sessions due to the crowds. One of the lesser attended sessions was about programming for the Windows CE platform. Microsoft has ported Windows CE to several microprocessors, and several manufacturers have released devices that use Windows CE.

The Windows CE user interface resembles a subset of Windows 95. It has a little desktop with a Taskbar and icons that open folders, documents, and applications. Instead of a mouse, you use the plastic stylus device, a pencil, or your fingertip to tap on the screen. A lot of the Win32 complexity has been exorcised from Windows CE. There are no MDI applications. The current application is always maximized. There are no OLE/OCX/ActiveX client/server objects. There is no printer port. There are no spinning media. There is no support for multimedia. Storage is RAM and ROM. Power consists of a RAM backup battery and two AA batteries. The serial port is for connecting to your desktop PC, although I am told you can connect to an external modem. There is one PCMCIA slot, but when I tried to put a Megahertz LAN/Modem PC card in, the operating system warned me that my batteries would not last very long. (You need the optional AC power adapter to use that PC card, which gets hot enough to heat this motorhome under normal laptop usage.) Windows CE multitasks and multithreads.

You develop programs for Windows CE by using Visual C++ on a desktop and a special SDK from Microsoft. The interface is seamless and well done. You can emulate the Windows CE screen from the desktop and debug an application from there. You can connect the Windows CE palmtop to the desktop and do some remote debugging, too. You program Windows CE with a subset of the Win32 API and MFC library.

After attending the Windows CE programming session at the Visual C++ conference, I shopped around and bought one of the little machines, a Casio Cassiopeia A-11. Wanting to learn its use before deciding what kind of program to write, I started to write this column by using Pocket Word on the Casio. After two paragraphs of Pocket Word on the tiny keyboard and barely readable screen, I gave up and moved the manuscript to the laptop. My small hands simply cannot navigate the tiny keyboard. And except under bright florescent lighting, the screen is nowhere near bright enough. The backlighting feature is stupid. There's no other word for it. If there is not enough natural light to read the screen without backlighting, there is not enough to read it with backlighting, either. Wherever you see these machines being successfully sold, you will see bright overhead lighting. Ask the dealer to let you try it outside on a cloudy day or in the back room. By the way, if you press the backlight button too hard, it presses the neighboring recessed reset key, which erases memory and powers the machine off.

Windows CE is being touted as the operating system for the next generation of embedded systems. You've heard the hype: Windows in your car, VCR, microwave oven, lawnmower, electric toothbrush, vibrator, whatever. Maybe, maybe not, but right now, it exists in mostly unusable palmtop computers. I do believe that despite the complete absence of a congenial user interface, which is a problem of hard ergonomics rather than operating-system deficiencies, this class of machine has some potential for vertical applications. You are not going to write anything of substance with Pocket Word, and you will not maintain your company's books in the embedded Pocket Excel Spreadsheet, but there has to be something that a Windows CE palmtop is good for. Otherwise, I'm out six hundred bucks, which would have paid for a lot of conch shells and T-shirts. Here's your chance to develop the next killer application. Unless you or somebody comes up with a compelling application, these machines are going to achieve the same obscurity that their ancestors, those pen-based palmtops of yore, already enjoy.

For me, I'm going to try to get the Casio to talk to my One Touch blood glucose monitoring machine. You will recall that, several months back, I built a data scope program to reverse engineer the serial protocols that the One Touch uses so that my PC could interface with the One Touch. I see a natural marriage between these two machines given the proper software. People who need to regularly monitor their blood glucose levels and record the details of their diet, exercise, and medication would benefit from such a program. The Casio and its hand-held ilk are a lot less expensive than the least of the laptop family.

DDJ