Rick Grehan
At first glance, Utah appears to be just another Windows GUI builder, or so I thought when I initially examined the package's documentation and explored the multimedia demonstrations supplied on the CD-ROM. I was skeptical, particularly when the documentation introduced Semantic Information Technology, a term that refers to the model at the heart of Utah. After all, the data-processing landscape is swimming with new "technologies," each poised to "revolutionize" the process of getting a computer to do useful work.
But Utah, which is sold by ViewSoft (Provo, UT, (801) 377-0787), is unique. Yes, it's visual: You click on a button to create a blank window and click on more buttons to populate the window with editable entry fields, scroll bars, radio buttons, or bit maps
. Yes, it's object-oriented: The on-screen items just mentioned are not treated as code resources; they are handled as discrete objects that respond to external events (e.g., a mouse-click).
However, Utah goes a step beyond. You don't just build a scroll bar as something to which you will later attach an activity. You can place a scroll bar on-screen only after you've defined a data item that the scroll bar will be linked to. The scroll bar becomes an alternate "view" of the data.
Here's an example: Suppose you had a numeric data-entry field that was a brightness setting for the computer's monitor--zero is completely dark, 100 is full intensity. You might want to provide a horizontal scroll bar in the form of a slider, just under the data-entry field, which the user could adjust with the mouse.
In the Utah way of building GUIs, these two items are alternate views into the same data: one textual, the other graphical. Utah doesn't let you build the data-entry field, build the slider, and th
en decide which data variable to attach them to. It does the opposite: You define a variable and then decide how it is to be represented and manipulated on-screen.
The result is that, in the example I've given, the data-entry field and slider are not only a means of modifying the variable, but they track the variable and are thus automatically synchronized with one another. Move the slider, and the number in the data-entry field increments and decrements; modify the content of the data-entry field, and the slider positions itself properly.
Building such objects in Utah requires no coding on the part of the designer. Utah emits the C++ code that you feed to either the Borland or Microsoft compiler. (I tested Utah with Borland's compiler. Utah prebuilds the project for you, ready to drop into Borland's IDE.) Better yet, even before you get to the compile stage, you can test your application in Utah's simulation mode. All the buttons, boxes, sliders, and data fields operate in simulation just as th
ey will in the final application. There's no compile-test-oops-recompile-retest cycle.
The Windows version of Utah costs $495. The NT version costs $695, but that includes the Windows version for free. By the time you read this, it's likely that the Unix version will be available. Utah arrives overflowing with bit maps, buttons, and sliders--everything you need to build a top-notch user interface. And because it's all C++, you can extend the existing set of objects to build custom versions of your own. Utah is definitely worth a look if your GUI building gives you headaches.