Technology and Community

Jim O'Neil

Subscribe to Jim O'Neil: eMailAlertsEmail Alerts
Get Jim O'Neil: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


PowerBuilder: Article

.NET Features Analyzer

Easing the .NET development effort

Here's a quick outline of the steps used to load the items in the unsupported features list:

1.  Locate the PowerBuilder IDE process(es). All PowerBuilder 11 instances have a main window with the class name PBFRAME110, so all running instances of PowerBuilder 11, their process ids, and their title bar text can be determined using the FindWindowEx, GetWindowThreadProcessID, and GetWindowText API calls.

2.  Locate the PowerBuilder Output window control. The Output window in PowerBuilder has the class name COutput so, given the handle of the main PowerBuilder window, FindWindowEx can be used to search all of the child windows for the one having COutput as the class name. Note, there is an implicit assumption that a PowerBuilder session has at most one Output window.

3.  Locate the Unsupported Features tab. The Output window contains a single Tab control and multiple ListBoxes. The COutput instance found in Step 2 is the parent for all these controls; the ListBoxes aren't contained in the individual tab pages as you might expect based on applications you've built with PowerBuilder. The relationship between each Tab page and its corresponding ListBox is maintained internally in PowerBuilder's implementation and not directly accessible to an external process. As a result, a small kludge (er...alternative algorithm) is necessary.

Knowing that the Unsupported Features ListBox includes a comment in the first line containing the text "Unsupported features:" a simple mechanism to find the ListBox is to iterate through all ListBoxes that have COutput as a parent and test each to see if it contains this eye-catcher text. Of course, should this text ever change, the algorithm will fail! Iterating over the ListBox classes is again done by FindWindowEx, while testing for the "Unsupported features:" text involves sending a few messages, via the SendMessage API, to the candidate ListBoxes.

4.  Copy each entry of the ListBox to a local Data-Store. With the correct ListBox found in Step 3, a series of messages is sent to that control, first to get the number of items and then to iterate through each item to access its text. At play here is again the SendMessage API using the ListBox messages LB_GETCOUNT, LB_GETTEXTLEN, and LB_GETTEXT.

Implementing Hyperlinks in PowerBuilder Painters.
As you know, in the PowerBuilder IDE you can double-click on references in the Output tab and jump to the painter and script associated with an error, warning, or search result. Internally, PowerBuilder associates a URL with each source code reference that appears in the various ListBox controls of the Output window. When an item in one of those ListBoxes is double-clicked (or Edit is selected from the context menu), PowerBuilder uses this internal URL to 'navigate' to the appropriate object painter and the line of code referenced.

The .NET Features Analyzer takes advantage of this same capability by communicating with the Unsupported Features ListBox in the open PowerBuilder session and mimicking a double-click (see the jumpToSource method in n_pbide). When the .NET Features Analyzer first loads the unsupported features list, it records the position of each unsupported feature reference in the ListBox. In response to a user clicking on a feature in the .NET Features Analyzer, two messages are sent to the PowerBuilder IDE's ListBox. The first LB_SETCURSEL makes the associated ListBox item the active one - you can see this first hand when the currently selected item changes. The second message, WM_COMMAND, includes argument values to indicate that a double-click event (LBN_DBLCLK) should be sent to that ListBox, thus feigning an explicit double-click gesture in that PowerBuilder IDE session. Due to the mechanism used here, be aware that the hyperlink functionality won't work if the Unsupported Features tab isn't the currently visible tab - after all you can't 'double-click' on something that isn't visually there, manually or programmatically.

The appearance of the hyperlinks in the Class View and PBL View DataWindows is implemented by simple expressions that change the properties of the one computed field at the detail level of the TreeView. The color, pointer, and font.underline properties of that field are expressions that access additional fields in the DataWindow (linenumber and idehandle) to determine if the unsupported feature reference includes an explicit source line of code and if the list originated from a currently active PowerBuilder IDE session. If neither of these conditions is true, the link capability and rendering are disabled.

More Stories By Jim O'Neil

Jim is a Technology Evangelist for Microsoft who covers the Northeast District, namely, New England and upstate New York. He is focused on engaging with the development community in the area through user groups, code camps, BarCamps, Microsoft-sponsored events, etc., and just in general serve as ambassador for Microsoft. Since 2009, Jim has been focusing on software development scenarios using cloud computing and Windows Azure. You can follow Jim on Twitter at @jimoneil

Comments (0)

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.