HomeCorporatePress CenterVisual Basic Tech Journal Review

Visual Basic Tech Journal Review

When I teach Visual Basic classes I admit to being a Microsoft Certified Professional and Trainer in Visual Basic I encourage people to raise issues and ask questions. It's not unusual to be asked about oddball but interesting topics, especially when we're discussing dull stuff like the difference between passing by value and passing by reference. I'm not the kind of instructor who says "If you don't stop asking questions, we'll never finish the material." I'm always happy to digress.

Most often, the questions are database-related: "How do l..." or "What's the best way to...?" Second on the FAQ list is something like, "How do I get some data out of an Access database and put it into Word or some other word processor?" In reply, I'll mention how you can control Word, in particular, through OLE and WordBasic. If I ask why they want to do it, the usual response has to do with the need to produce output that looks like a memo or a letter and not like a typical tabular report. The questioner wants to control type faces, font styles, and effects. For instance, one student wanted to improve his company's software-requisition system. In the old system, a developer typed a memo requesting a piece of software and put it into a common directory on the network. The developer then called purchasing to tell them to pick up the memo. The purchasing person opened the document, typed it up on letterhead, and sent it to a verdor. Weeks would pass. One day the developer reached for the new software, but it wasn't there. The developer would track down the original request, the purchasing agent would find the purchasing copy, and then someone looked up the vendor's phone number and called to see whether they got the order in the first place.

I suggested a different system: The developer makes the request in an e-mail message to purchasing. Purchasing generates the purchase order created in a word processor controlled by Visual Basic and faxes it to the vendor.

This example of creative genius usually gets the attention of the class members, but then I rain on their parade. I mention that even though using a word processor works nicely, it leaves a good-sized memory footprint. And what if a number of purchasing people need a copy? And what about the intricacies of WordBasic? The students frown, realizing that this problem is bigger than a breadbox. "You might want to think about an RTF-type control," I say. "It doesn't cost much, and it doesn't have these problems." Now I really have their attention. Then, alas, duty calls and it's back to passing by reference. But there's nothing like an enraptured and intelligent audience of readers to inspire me to delve deeply into something I find fascinating. Intelligent you are but enraptured... hmm. I've got it! Watch the watch. You're getting very sleepy...

It's rich, it's text, it's formatted

The rich text format spec, designed as an import-export mechanism between programs, contains all the information a program needs to accurately display and print formatted text created by another program. RTF controls are components that read and write RTF files. The advantage of RTF is that it can be built into a package that otherwise would have to use a filter or translator to read a document file produced by another application.

Although it was created by Microsoft, RTF is an ASCI1-based, nonproprietary specification for use by anyone under any operating system. Almost every word processing package on the market reads and writes RTF files. RTF supports font styles (including bold and italic) and font effects (including strikethrough and underline).

RTF is character-specific. In contrast to the characters contained in a text control, in which every piece of text gets the font treatment specified in the property sheet, each character in an RTF document can be controlled individually. One character in a paragraph can be bold and the rest normal. RTF supports formatting for a sentence, a paragraph, or an entire document.

RTF also supports colors, indentation, justitication, margins, tabs, font names, and more. The latest spec, version 1.4, supports tables, something that developers have wanted for a long time.

Reading and writing for real

Knowing the specitication is one thing; implementing it is another. The Microsoft Developer Network CD-ROM contains the entire RTF spec as well as sample code - in C, naturally - for creating an RTF reader and writer. After looking through the code, you should have no doubts that, in the case of reading, writing, and displaying RTF files, buying is better than building.

Deciding what to buy begins with a simple question: Do you want to read only or to read and write? (We'll assume that you want to display formatted text contained in an RTF file.) If you just need to read a file, there's no need to provide the ability to format text. Things like a toolbar to set fonts, style, or justification - or even a way to format text programmatically - are not very important. But toolbars and programmatic interfaces are more important when you want to be able to write an RTF file.

You maybe thinking that all this sounds like creating a word processor. You have one - say, Word - that's more than adequate, and it can produce RTF files. So why go through all this trouble? There are a couple of reasons. The translation From a Word DOC file to an RTF file suitable for loading into some other app's RTF control is not exact. Word supports a great deal of formatting that is defined in the RTF spec but which does not survive when the document is saved as an RTF tile. There is no stamp of approval from Microsoft or anyone else that certifies that an RTF control supports all or part of any version of RTF. If you want to ensure that an RTF file can be displayed by an RTF control exactly, it's best to create it in the RTF control in the first place. In that case, it may be important to you that an RTF control help you by supplying a toolbar or by making it easy for you to construct one. Another reason is that there's significant overhead in terms of memory and OLE performance - you can't expect everyone to have a copy of Word on his machine.

How Do You Spell...?

Spell-checkers are of obvious use when you're using an RTF control, but they also come in handy in places you might not have thought of. When you're developing an application for data entry, you probably make users'lives as easy as possible by providing listboxes so that they can pick a valid choice rather than type something that must be checked for errors. But the entries in the listbox are also created by a fallible human being. A part of the application makes sure that there are no duplicates in the list, but "New Yurk" can easily "New Yerk," "New Yirk," and "New York." How can you prevent this kind of error'. Use a spell-checker when building look-up tables. It is so obvious that you wonder why more shrink-wrap apps don't use them. The venerable Quicken - at least the old copy I have - doesn't have one. I set up my 1995 subscriptions to Oakley Publishing, but when I went to check on how much I had spent, I typed "OA" and came up with nothing - I had spelled it "Okley." Even though "Oakfey" isn't in Webster's dictionary, a spellchecker would have flagged it and I might have noticed that I had spelled it wrong.

Spell-checkers are frequently accompanied by a thesaurus. Roget's is great; however, on trans-Atlantic flights, users might forget to pack it. They will appreciate the inclusion of a comprehensive thesaurus. Consider it a plus for a spell-checker to have a thesaurus, and a double plus if users can update it.

Spell-checkers are measured against the standard: the Word for Windows spell-checker. The basic functions - Change, Ignore, and Add - must be present to minimally qualify a spell-checker as worthy of attention. Ignore All and Change All functions are also musts, as is a list of possible correct choices. Many words sound or are spelled alike, and spell-checkers, for all their sophistication, aren't very good at figuring out the word you mean just by the context or by means of telepathic emanations, no matter how hard you glare at your monitor.

Users of spell-checkers are comfortable with the dialog that appears in Word. Although you can improve on it, many spell-checkers supply a built-in dialog with a similar look-and-feel. You can save yourself hours of work by using it.

If you're sold on RTF controls and spell-checkers, don't go out and buy one just yet. I took a look at four RTF controls and four spell-checkers. Let's see how they stack up.

VisualWriter

VisualWriter is an RTF and word processor tool that is designed for use in Visual Basic applications in which documents, rather than fields, are the key elements. VisualWriter is virtually identical to its sibling, TX Text Control (reviewed next), which, according to the copyright mark, is made by the same company (DBS, Bremen, Germany). Because VisualWriter and TX Text Control are so much alike, I have deferred a full discussion of the features of both products until the next section. Here, I'll point out the differences that might affect your buying decision. One difference is that VisualWriter is part of the Visual Developers Suite Deal, a bundle that includes the Formula One spreadsheet control, First Impression charting tool, WebViewer browser, and VisualSpeller, a spell-checker reviewed later in this article. The tools in the Visual Components bundle are distributed on CD-ROM.

Another difference is that VisualWriter and its suitemates do not come with printed documentation. You know how cereal companies size their boxes so that it looks like you're getting more cereal? They tell you that the product is sold by weight and not by volume. The contents, they say, may have shifted during handling. Call me old-fashioned, but if a software vendor is going to subliminally equate the size of the box with the quality of the software, it ought to explain why there's a cardboard spacer where the manual should be. If you want printed documentation, you'll have to plunk down $75 for the bundle ($25 for any one product). The free documentation for VisualWriter is contained within a help file that's a nearly verbatim copy of the printed documentation that comes with TX Text Control.

VisualWriter adeptly integrates the VisualSpeller spell-checker. You simply use the VTSpellCheck method of the VisualWriter control to spell-check an entire document or highlighted word. TX Text Control, too, is designed to integrate with VisualSpeller.

The most important difference between the two products is price. The bundle mentioned above is priced at $299. By itself, TX Text Control costs $249; with its add-ons (TX Publisher and TX Info Artist), it's $499, and you still don't get a spell-checker.

At one point, TX Text Control was a better choice because of its greater number of features; a product called VisualWriter Pro was its equivalent. The current 0CX versions of both products are now the same. Because of the additional tools that are part of the Visual Components bundle, I'd have to recommend VisualWriter over TX Text Control.

TX Text Control

The twin brother of VisualWriter is TX Text Control, which is distributed in North and South America by Griffin Technologies. One immediate distinguishing feature of TX Text Control is its excellent written documentation, which comes with the product at no extra charge. It includes a general reference, a reference to the underlying DLL, and even a Visual Basic user's guide. I'm usually content to work with a product's help file. Even though TX Text Control's help file is more than adequate, the manuals are a bit better organized. For a quick syntax check, I found myself using the help file; for more in-depth musing about properties and events, I was glad to have a book to scribble in.

TX Text Control (and VisualWriter remember, except for the price and documentation, these are the same product) consists of one control that turns up as four tools: the text control itself, a toolbar, a status bar, and a ruler. Putting together a basic word processor takes about five minutes. You add each control to a form and specify, in the property sheet of the text control, the names of your toolbar and status bar. You can have multiple text controls, tool-bars, and status bars, but if you have only one of each, these names are plopped into the text control's property sheet for you. You might want to add a menu item to save the contents of the text control to an RTF file, and another item to open a file. You'll probably want to spend another five minutes putting a common dialog control on your form to make opening and saving easier and more professional.

There's more to it than that, naturally. You'll need to be concerned with margins, tab settings, and printing. Interestingly, there are a couple of properties that, when set to True, display built-in dialog boxes, Although these dialogs are certainly handy (no coding!), they might not correspond to the look-and- feel of your application. There's no other way to set these properties. I'd like to see these built-in dialogs go away or be made opt ionaL The properties, methods, and events of a tool are the vendor's choice, but what gets displayed on the screen should be up to the developer.

With TX Text Control, the real treat is fields. You couldn't ask for an easier way to mix boilerplate text with variable text. TX Text Control fields can be more generically referred to as mail-merge fields or bookmarks. You create a field by assigning text to the FieldInsert property. You have full control over the appearance of the text in a field, and if the data changes, you assign new text to the field. Wordwrap and pagination are taken care of for you. I haven't tried to put the text of War and Peace into a TX Text Control field, but there's no practical limit to the amount of data that can be placed in a field.

Although TX Text Control and the other RTF controls in this review read and write RTF files, they also have their own proprietary binary formats, which in the case of TX Text Control and VisualWriter is the only way to save a field and its contents. The RTF specification supports fields and bookmarks, but TX Text Control does not read or write those attributes.

TX Text Control easily handles most of the tasks that you might expect of a word processor control. Images can be included in a TX Text Control document in two ways, both of which use a built-in image control. The Imagelnsert property embeds an image at a character position within the control. By itself, this arrangement isn't terribly useful because you can overtype or backspace over the image. Embedding an image in a read-only TX Text Control that is overlaid with other transparent controls, however, is a good way to create a watermark or letterhead.

More useful is the ability to insert images as objects by assigning the ObjectFileName property to a valid image file or to the hWnd of any other window. Text can be made to flow around the inserted control. The documentation says that the inserted object can be an OLE control, but exactly what that means is not clear. Inserting images by file name is the only technique that's documented or shown in the sample programs. Once an image is inserted as an object, it can be moved and resized. You can click on the image and display a dotted-line border, but you must press and hold the Alt key to grab the border for movement or resizing a requirement that's hardly intuitive.

lf you're using images and importing and exporting text files, you'll have to distribute more than a few support files along with the VBX or OCX files. Three DLLs support the basic functionality; another DLL is used for RTF import and export, and five files are used for the imaging functions. These files aren't particularly large, but you'll have to remember to include all of them when you're constructing a set-up program for your application. TX Text Control goes beyond VisualWriter with the addition of two optional add-ons. TX Info Artist is an online documentation authoring tool You could use it to build documentation much like Microsoft's Books Online or the documentation that is supplied with Visual-Writer on its CD-ROM in lieu of a printed manual TX Publisher aims to be a frame-oriented addition that lets you position text frames anywhere within a document. These frames can hold text or OLE objects like an Excel spreadsheet. The behavior of TX Publisher is somewhat quirky. Frames appeared and disappeared and were sometimes painted with a gray background. An Excel worksheet object intermittently could not be moved or resized. TX Publisher appears to be a great way to generate variable documents, such as contracts that may or may not have certain clauses, by the addition, deletion, or positioning of frames containing text. TX Publisher is a new product in the TX line that I hope to see further developed and stabi1ized.

The documentation that comes with the various TX products is not voluminous, but it is adequate. The numerous sample Visual Basic projects that accompany TX Text Control, TX Info Artist, and TX Publisher give you plenty of code to help you build any application that needs to use formatted text. You should include TX Text Control and its siblings when you're looking for an alternative to controlling a hefty word processor from Visual Basic.

AIIText 4 HT/Pro

Unlike TX Text Control and VisualWriter, AllText is not described in the accompanying promotional literature as an add-on word processor component. It comes without a toolbar, status bar, or ruler. Evidently the folks at Bennet-Tec feel that if you need such things you can easily implement them yourself. They might be right about the toolbar and the status bar, but I'm not so sure about the ruler.

The toolbars that come with TX Text Control and VisualWriter feature the components you'd expect, like font dropdown lists and bold, italic, and underline buttons, though these are certainly easy enough to create yourself. AllText provides a pop-up font dialog and properties for setting font styles and alignment. But if the application produces formatted text, it's more than just nice to have tab and margin controls included within the control - they're not quite as easy to implement on your own.

Just look at the sample code supplied with AllText. Here a ruler is constructed from images and picture boxes. The ruler's implementation uses three modules, and the code includes calls to both AllText's and Windows' API. That's an awful lot of work to achieve something that TX Text Control and VisualWriter do right out of the box. The code needed to implement a toolbar is equally daunting.

Some of AllText's features can be set with properties, but most of the work is accomplished via calls to the AllText API. The manual includes a thorough reference to all of the functions, as well as the properties and events associated with AllText. AllText events are much like those you would expect from a plain text box, but there are some unique ones that are quite useful. You can use the ATXChangeEvent to update a status bar so that the current page, cursor position, and line number are displayed. Other information is available from this event, such as font style or name - you could use that to update a toolbar.

Some properties that work better with AllText than they do with TX Text Control and VisualWriter. The LineSpacing property gives you twip-level control over line spacing, but TX Text Control and VisualWriter allow only single, 1.5 line, and double spacing. AllText's TopIndent and BottomIndent properties, which control paragraph spacing, give you full control over the document's format. Other properties that I found useful were PageLineNumber and the PageNumber. After a document has been formatted for printing, you could use those properties to determine if a page is blank. It's not uncommon to insert page breaks in a document, but when a document is changed programmatically (perhaps by adding text from a database), a page break can sometimes come at the end of a page, resulting in a blank page. Before you print, use All-Text's PageNumber property to scan the document for blank pages. If the PageLineNumber property returns zero (the first line on a page is line zero) and moving to the next line changes the contents of the PageNumber property, then you know there is a blank page in your document. If you want to print a blank page, set the SkipPageFlag to True. Neither TX Text Control nor Visual-Writer can search for blank pages programmatically.

AllText does not support fields, but the documentation details a workaround that lets you create the functions that are already included in TX Text Control and VisualWriter. This is true of many of AllText's features, making it cnsiderably more complicated to use.

AllText handles font selection in an unusual way. AllText does not have a built-in toolbar that includes a dropdown font selector. Setting the F2On property to True causes the font common dialog to appear when the F2 key is pressed. You can change the current font or the font of selected text. Because using F2 to change fonts is not exactly intuitive, you'll either have to document it or include a menu item or toolbar button that sends an F2 keystroke to AllText. The documentation points out that this can be done by using SendKeys. From the user's point of view this doesn't matter, but a developer might find the workaround rather lame. The number of files that must be distributed with an AllText application is smaller than the number of files needed for a TX Text Control or VisualWriter application. In addition to the OCX, you need include only an OLE DLL and an image DLL. You are less likely to overlook necessary files during distribution a plus for AllText.

Like the control, the documentation is quite technical. It warns: "this section is for even more aggressive users and may certainly be ignored by the less daring." Whew! I was forced to read the section just to maintain my self-respect. The documentation also refers to AllText's lack of table support something TX Text Control and VisualWriter lack as well and says we can expect table support in the fall of 1995. (Ed. Note: According to Bennet-Tec, AllText will include table support by the fall of 1996.) AllText provides a great deal of sample code that sets shadow borders, underlines text, indents paragraphs, and prints. There's also a sample text editor, complete with toolbar and ruler. Compared to TX Text Control and VisualWriter, AllText requires a significant amount of code, but you can control things down to the smallest detail. AllText can grow on you. Though it's not particularly developer friendly, no doubt AllText can do whatever you want to do with a formatted-text editor. (Ed. Note: At press-time, Bennet-Tec released what it describes as a substantial update to AllText.)

TE Developer's Kit

First impressions count for quite a bit with me, and my first impression of the TE Developer's Kit was not good. There was no set-up program, and the documentation looked as if it had been run off at the local OfficeMax. I wasn't any happier after I looked at the documentation and saw C code and seemingly endless references to function calls. But being the persevering Indiana Jones type of guy I am, I snapped on my programmer's fedora and plunged in.

I didn't find the most beautiful RTF control in the world, but I did find a serviceable toolbar with a font dropdown list, an equally serviceable ruler for setting tabs and indents, a truly ugly status bar (which I turned off immediately), and a built-in menu. Of all the products reviewed, TE Developer's Kit is the only one that supports RTF tables. I created a table using TER (as Sub Systems calls the control), saved it as an RTF file, and opened it in Word for Windows. Word welcomed the file graciously. I modified that table, created another, saved it as an RTF file, and loaded it into TER. With equal aplomb and nary a burp, TER displayed the table perfectly. I think that a quiet "wow" escaped my lips. Tables are a sort of Holy Grail one I hadn't expected to find. I knew then that this RTF editor Form was worth looking at C code and all.

TER is implemented chiefly as a DLL; there's a VBX wrapper for some of the more accessible attributes. A 32-bit OCX version is said to be available, although I didn't receive it. The package also includes a code module that contains global constants, type structures, and declarations for all of the functions. TER supports multiple-column documents, merge fields, Footnotes, headers and footers, print preview, repagination, as well as input and output to RTF and proprietary-Format files. TX Text Control, VisualWriter, and AllText don't support multiple columns, footnotes, or repagination. AllText has internal headers and footers, while TX Text Control and VisualWriter use separate instances of the editor control for headers and footers.

TER is shipped with source code, and Sub Systems provides an example that details the incorporation of spell-checking into the TER DLL. What I could not find, in regard to spell-checking, is an obvious way to retrieve selected text in order to spell-check a single word or paragraph. TER does not have a SelText property, nor is there an easy way to select text at a particular cursor position. AllText, TX Text Control, and VisualWriter all have SelStart, SelLength, and SelText properties.

The biggest problem with TER is its lack of Visual Basic friendliness. Although there are VBX and OCX interfaces, the properties they provide are not extensive. You're obviously expected to use the API functions declared in ter.bas to get real work done. I have nothing against this approach the rewards are commensurate with the effort. It's just that as Visual Basic developers, our goal is to produce sooner rather than later, and using TER's 89 API functions and their accompanying structures, which have upwards of 60 fields, means that using TER to build an application will take much longer than it would with one of the other products I looked at.

I can recommend TER to the Visual Basic developer who has time to experiment and learn the functions and operations. Once you get past the steep learning curve, you'll find TER includes features table support, for instance that you won't find in other RTF controls.

Some remarks from the webmaster

This review was scanned and OCR'd from a printed copy of VB Tech Journal. Differences to the original text are unintentional. Although it was released back in 1996 and therefore does not describe the latest versions of the tested products, it presents a good overview of the available tools and gives valuable hints on how to compare them.

Among the things that have changed since the release of the review are:

1. Visual Components have stopped distributing VisualWriter. The spell checker, however, is still available
2. Griffin Tech is no longer distributing Text Control
3. Text Control's version number and price have changed
4. Most, if not all, of the features Jeff feels are missing have beeen included in later versions. Please refer to the online documentation to see if a feature or property you are looking for is available

Visual Basic Tech Journal