Page 1 of 2   next page »

One new long-anticipated feature of PowerBuilder 10.5 was originally planned for the PowerBuilder 10.0 release: the new Rich Text Edit (RTE) control. The original RTE control (see Figure 1) was introduced into PowerBuilder before Microsoft implemented a Rich Edit Control within the Windows Common Controls. Since there wasn't a "standard" rich edit control in the operating system, many developers were using third-party controls to implement such functionality. In addition, at that point, cross-platform availability was a requirement, since PowerBuilder was available for development on Mac and UNIX platforms. One of the most popular third-party controls was called HighEdit, and the original PowerBuilder RTE control was an OEM version of that control.

Some time after the original PowerBuilder RTE control was introduced, the original vendor of the control not only discontinued support for it, they exited the third-party control market entirely. As a result, the functionality of the control was largely frozen, while at the same time the expectations that users had for the functionality of such a control continued to evolve and expand. In particular, the look and feel of Windows applications has changed over time and the Rich Text Format (RTF) standard for the text the controls should work with has been updated several times since. As the years went by, the original control became more and more dated.

That has all changed with the introduction of a new RTE control in PowerBuilder 10.5 (see Figure 2). Rather than introducing a second RTE control and continuing to support the original RTE control for backward compatibility, Sybase has instead chosen to replace the original RTE control with the new one. The idea was to provide as much backward compatibility for the old control as possible, and yet also provide much more support for the newer features that end users are expecting.

The use of the RTE has typically fallen into three categories:

• Load rich text data from either files or the database, maybe allow editing, and maybe allow saving of the data to either file or database
• Data entry from an empty control
• Programmatic data population of the control

Loading and Saving
The obvious change you'll see first in loading rich text documents is the fact that more rich text features, like tables, are loaded successfully. While this does not support 100% of the features found in Word's rich text export, you'll find most of the features your users will expect as basic word processing functionality. One way the new control imports more elegantly is the manner in which it deals with features in the imported files that are not supported. In the old RTE control, unsupported features often showed in the control as uninterpreted rich text code or some other meaningless code. In the new control, the unsupported features are cleanly stripped out. This makes for a much less confusing experience for the user.

Users loading rich text had to convert their documents from some other format to rich text. This step may be eliminated in the future for many with the addition of import support for Microsoft Word (DOC) files and HTML files. In some random testing, we've had varying success loading HTML files, particularly showing problems loading graphics from other directories. Still, this could become a relatively easy way to load basically formatted text into the RTE control. Word document loading was much more successful. Word documents imported natively preserved the format better than the same documents exported from Word as rich text, and then rich text imported to the RTE control. Similar to rich text import, features that aren't supported by the control are stripped out.

Not only does the new control load new document types, it also jacks up the number of picture formats it supports from one to six. The old rich text control handled only BMPs. The new control can load:

    •    BMP
    •    WMF
    •    TIFF
    •    JPEG
    •    PNG
    •    GIF

While this doesn't add a new file format support to PowerBuilder overall, this means the RichTextEdit edges out the InkPicture control as the control with the most number of supported picture formats.

Saving from the RTE control has also been beefed up. The old control could save its contents as plain text or rich text. The new control adds HTML, Word DOC, and Acrobat PDF to the mix. The Acrobat document generation is done internally without Ghostscript, easing the stress some people had about deploying Ghostscript. These saving options open up a whole new realm of document-generation options for applications.

One of our first inspirations when we heard about the new import/export options was around the DataWindow. The DataWindow can export HTML. The RTE control can import HTML, then export PDF. Could this be a new solution for PDF deployment without Ghostsciprt? Unfortunately our testing only produced respect for the DataWindow print engine and for the difficulty involved in loading HTML. While the concept looked good on paper, in reality it fell short. The new RTE control had problems properly identifying the correct border type to apply to the tables that are used extensively to handle text positioning (the RTE control created visible borders instead of invisible), and HTML documents wider than the page don't produce the horizontal page break that the DataWindow handles so elegantly.

Data Entry
When providing the RTE control for data entry, the first thing your user will recognize is the new look. Gone are the Win3.1-style toolbar; it's replaced with one that looks more up to date. In addition, a status bar that is common in so many applications is now available along the lower edge of the control. Of course, both can be turned on and off with simple attributes, either in the painter or at runtime.

The Properties pane for the new RTE control has a new Font tab page (see Figure 3) in which you can set the default font face, size, and style for the control. Previously it was somewhat ironic that the only PowerBuilder control with a text attribute that you couldn't set the default font face and size for was the RTE control. There were some workarounds for this, but they involved calling some officially unsupported native methods of the underlying third-party control. Finally, with this new control, that long-standing issue has been resolved.

Still more functionality becomes available when you consider that since Microsoft standardized the API for rich edit controls when it introduced them into their own custom controls, a third-party market has developed for tools that interact using that API. Since the new RTE control largely implements that API, there are a number of utilities out there that can be used to extend the functionality of the control.

Probably of most interest is the addition of a spell-checking capability for the control. Because the original control didn't support the rich text control API, spell checking with it usually involved extracting the non-RTF text from the control and spell checking it. This would usually result in a loss of formatting of the text. Now that the new controls support the API, spell checking becomes a possibility, even to the extent of auto spell checking (where the spell checking is done as you type in the control).

We'll look at implementing spell checking using three different add-on spell checkers:

• JRSpell from JR Software: www.jrsoft.de/JRSpellCheckere.html
• WSpell from WinterTree Software: www.wintertree-software.com/dev/wspell/
• VSSPell from Component One: www.componentone.com/products.aspx?TabTypeID=1 &ItemType=1&PanelIndex=16&ItemID=54015& SubCategoryTypeID=0&TabMapID=92&TabID=111

The window with a title of "RTF Control" and a class name of "FNWDN3105" is the parent window that we've put the control on. The class with no title and the class name of "PBRTC105" is the RTE control itself. You can then see that it's made up of the PBTxtButtonBar, PBTxRuler, PBTxStatusBar and PBTxTextControl controls. And finally, within the PBTxTextControl class is an AfxOleControl42u class object, and within that is the TX11P class object that we're really interested in.

Each of these spelling controls is an ActiveX, so what we created a custom user object for each type olecustomcontrol to serve as a reusable wrapper for them and associated the custom user object with each ActiveX. Then we declared the following local external function in each:

Protected Function ulong FindWindowEx( ulong hwndParent, ulong hwndChildAfter, string
lpszClass, long lpszWindow ) LIBRARY "user32.dll" ALIAS FOR "FindWindowExW"

Page 1 of 2   next page »