From the Editor-in-Chief of PowerBuilder Developer's Journal

Bruce Armstrong

Subscribe to Bruce Armstrong: eMailAlertsEmail Alerts
Get Bruce Armstrong via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

PowerBuilder: Article

New Rich TextEdit Control for PowerBuilder 10.5

A much-needed improvement

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
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.

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.

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services (www.get-integrated.com). A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

More Stories By Terry Voth

Terry Voth, an independent consultant, has worked with PowerBuilder for over 10 years, and in the computer industry for over 15 years. He has extensive experience in both the public and private sectors, primarily in Ontario, Canada.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.