The Design and Implementation of VIOWIN - Part 7

Written by Larry Salomon Jr.

Introduction
For my job, I once had to write an application that ran only when OS/2 booted from the floppy diskettes. Because I had no access to the functionality PM provides, I resorted to a line-oriented interface, where messages were displayed on the screen and scrolled up when necessary. It was a good interface, I thought; it was fully NLS enabled and had intelligent defaults so the user basically only had to type in the name of the application. Unfortunately, the Quality Assurance team didn't concur with my opinion. "We want a nice interface!" one exclaimed. "Yeah, one with different windows and such!" another shouted.

I was backed into a corner that I could only get out of one way.

This series describes the design and implementation of VIOWIN, a library that implements a subset of the Win APIs provided by PM for fullscreen sessions. The reasoning behind writing this series is that it provided me and will hopefully provide you with some unique insights into how a windowing system is developed; and since it is based on PM, your familiarity with the already defined interface will increase your capability to fully understand what is being described.

Obviously, this series assumes you have PM application development experience, but it isn't required.

This Month
This month, we will look at the VWWC_STATIC class as implemented in the library.

Static Controls
VIOWIN implements two types of static controls only: text and groupboxes. These were chosen because they are the most widely used (from my observations), although other, non- graphically oriented ones could also have been implemented.

Statics, as you are well-aware, are idiot-controls - they do absolutely nothing except paint themselves. This makes our job much easier, since there is no need for instance data or complicated processing of user-input.

There are three helper functions used by the static control:
 * paintText - paints the text including handling the DT_WORDBREAK style.
 * drawLine - paints any one of the four bounding lines of a groupbox.
 * paintGroupbox - paints the groupbox.

The paintText Function
The paintText function is fairly easy to digest because the hard work is done by the vwDrawText function which was looked at earlier in this series.

The only thing that it needs to do is avoid drawing extra white space at the beginning of a line, which it does by scanning for the first non-space character in the DT_WORDBREAK loop.

The drawLine Function
The drawLine function is another easy-to-digest piece of code because its purpose is simple: draw a horizontal or vertical line which will be joined later by other lines at its two corners. Thus, the appropriate corner character needs to be drawn as well as the line proper.

The paintGroupbox Function
The paintGroupbox function was removed from the window procedure to keep it from getting crowded, but there is no other reason why this was done. It calls drawLine once for each line and then draws the text of the groupbox in the top border.

The Window Procedure
The window procedure does nothing except paint itself during WM_PAINT and signal that it needs to be repainted when the window text changes. How much easier do you want?

Conclusion
Okay, I'll admit that I chose this window class this month because I knew there was nothing to it. However, it does demonstrate that PM isn't as mysterious as you believe, at least for the parts which have analogies in VIOWIN. Next month, we'll wrap up the series with a look at the VWWC_BUTTON class which is arguably the most complex of the classes.