PB 10.5

The FindWindowEx function searches for a child of the window represented by the hwndParent handle, beginning after the child window represented by hwndChildAfter, whose class name is lpszClass. The lpszWindow argument can be used to pass in a string with a window title. We won't be using it, so we've declared it as long instead and will be passing 0, which passes a null to the function so that all window titles (or none at all) are matched. I'll also be passing a 0 for the hwndChildAfter to tell the function to start its search with the first child window.

For the function that we created on those custom user objects to tell them to spell check the text in the RTE, we pass in an object of type richtextedit (the parent PB control). Within that function, we use the following logic to get the handle of the internal rich edit area:

ulong       hWin

hWin = Handle ( a_rte )
hWin = FindWindowEx ( hWin, 0, "PBTxTextControl", 0 )
hWin = FindWindowEx ( hWin, 0, "AfxOleControl42u", 0 )
hWin = FindWindowEx ( hWin, 0, "TX11P", 0 )

The last value of hWin is passed in as the parent in the subsequent call because these classes are actually nested within each other.

Beyond this point, the way the spell checking is implemented is entirely dependant on which utility we are using. The JRSpell requires a bit of set up in the constructor event to set the language used and the location of the dictionary file (see Listing 1). The VSSpell only requires a reference to the dictionary file:

this.object.MainDictFile = "VSSP_AE.DCT"

and the WSpell didn't require any setup code at all. For the JRSpell utility, the spell check is initiated through the SpellCheckWithDialog function:

this.object.SpellCheckWithDialog ( hWin, 0, 3 )

where the handle to the rich edit area is passed in (hWin) along with the start position (0 to start at the beginning) and the user object type (3 meaning TX Text Control). For VSSpell, the spell checking is initiated through the CheckWindow function:

this.object.CheckWindow ( hWin )

where the handle to the rich edit area is passed in (hWin). For the WSpell utility, we set a few properties (including assigning one the handle of the rich edit area) before we call the Start function (see Listing 2). Finally, the WSpell and VSSpell utility will automatically replace a misspelled word with the correction selected by the user. However, the JRSpell utility calls only a changeword event on the spell-checking control, passing in the replacement word. The developer has to do the actual replacement of the text. Fortunately, that's easily accomplished by calling the ReplaceText function on the PowerBuilder RTE control:

i_rte.ReplaceText ( newword )

Automated Data Fill
This new control updates rich text support from "a subset of the 1.2 specification" to "a subset of the 1.6 specification." While the specifics of "what is the subset" isn't defined, one thing this upgrade has added that was sorely missing was support for tables. Now, for example, we can create tables of rows of data and include that within a generated letter. The primary downside of the table support is that there isn't a means in the RTE toolbar for the user to add tables, so you'll have to create your own PowerScript to PasteRTF() a table into the control. To give you a headstart on building a basic routine, we've included a sample with some presumptions, such as table width and border type (see Listing 3).

Other features now supported include:

• Double underline
• Paragraph shading
• Paragraph borders
• Headers/Footers

Caveats
Sybase has gone to great lengths to maximize compatibility with the previous RTE control, including rejecting use of the Windows standard RTE control. Doing so put off the upgrade of the RTE control originally planned for PowerBuilder 10.0, risking the wrath of us, the PowerBuilder user community. Obviously, compatibility was important. While important, it wasn't 100% achieved. Our opinion would be that documented incompatibilities aren't significant. For example, ReturnsVisible, SpacesVisible, and TabsVisible have all been replaced by ControlCharsVisible. We're not picturing users running screaming down the halls because they can't make their returns visible and their spaces invisible. Then again, we haven't met your users. The help file in the release candidate we're looking at while writing this article documents other changes about as equally alarming to us. Then again, we haven't seen your application. Do your homework. Read the documentation (as you should with all changes in all releases) and make sure that the changes don't affect your application adversely.

Conclusion
The new Rich Edit Control provides some much-needed improvement to the rich formatted text handling capabilities. Features like new import and export types will provide your users with benefits almost immediately after upgrading. Other features, like the API that facilitates spell checks, create opportunities for your application further down the road.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...