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

Enter the .NET Features Analyzer, a PowerBuilder utility that presents the unsupported features list in two TreeView formats - one arranged by PowerObject class, the other by the objects in your PBLs. Features can be filtered as well, so items of minimal impact to your application can be removed from view as you do your analysis. Like the Output window in the PowerBuilder integrated development environment (IDE), the .NET Features Analyzer provides hyperlinks that navigate directly into the script painter to the line of PowerScript that references the unsupported feature. In this article, we'll take a quick tour of the utility and peek under the covers at some techniques you may find useful in your own applications or utilities.

To start, you can download the utility (including the source code) from Sybase's CodeXchange site at http://powerbuilder.codexchange.sybase.com/ under the IDE Utilities section. A simple setup program searches for your PowerBuilder 11 installation and puts the utility's executable file (nfa.exe) and a help file in a newly created Add-ons directory below your PowerBuilder 11.0 directory. To provide access directly from the PowerBuilder IDE, the .NET Features Analyzer appears as an option in the File>New dialog, as shown in Figure 2. Did you know you can add your own items to the File>New dialog as well? Check out "How'd he do that" at the end of this article to learn more.

When you launch the .NET Features Analyzer, you'll see a simple blank tabbed interface. First you'll need to select the source of the unsupported features list: either an open PowerBuilder IDE session (using the File>Import from Output Window menu item) or a file (using the File>Open... menu item) containing the unsupported features list saved from a previous .NET deployment.

Electing to import the unsupported features list from the Output window presumes you have an open PowerBuilder IDE session from which you've just deployed a .NET target. If you happen to have several PowerBuilder sessions open, you'll be prompted to pick one. Once the targeted PowerBuilder session is known, the .NET Features Analyzer populates its own internal structures with the data appearing in the Unsupported Features tab. If you choose to pull the data from a file you saved previously, the data will be read in from that file, of course. Check out "How'd he do that" at the end of the article for insight in to accessing a PowerBuilder IDE session from an external program.

Each unsupported feature reference is reported as a fairly well-structured message that includes the name of the object referencing the feature, the unsupported feature itself, and the context in which that feature is used, including a source code line number. As each message is read from the IDE or file, it's parsed via a finite state machine (see the processFeature method of the n_featureList custom class user object). The feature information is then added to a main DataStore object used to provide the data for three different views in the .NET Features Analyzer:

  • The Class View (Figure 3) shows the unsupported features arranged by PowerObject class,
  • The PBL View (Figure 4) shows the features organized by the objects in the PowerBuilder library file, and
  • The Input tab (Figure 5) echoes the unsupported feature output as originally presented in the PowerBuilder development environment.
A fourth tab, Exceptions (Figure 6), can be hidden if desired; it contains entries from the Unsupported Features tab that weren't recognized as specific feature instances - such as the comment lines that show at the beginning and end of the unsupported features list.

Both the Class View and PBL View organize the feature list into five TreeView levels, with the lowest level referencing each specific instance of an unsupported feature in the source code or object definition. A context menu on each TreeView enables you to quickly collapse or expand to one of these five discrete levels. If the list was obtained from an open PowerBuilder IDE session, the items at the detail level of the TreeView (as well as all the lines on the Input tab) act as hyperlinks to open object painters to the relevant line of code within that PowerBuilder session. How do the hyperlinks work? See "How'd he do that" at the end of the article.

By expanding the Class View tab to the third level (Unsupported Feature Level in the context menu), you can gain quick insight into where the unsupported features are concentrated. Figure 7, for example, shows that the Web Reports sample application shipped with PowerBuilder 11 includes a total of nine references to the LiveScroll property of the various DataWindow controls used in the application. (LiveScroll controls whether the DataWindow contents scroll as you move the thumb control on the scroll bar). Although this property isn't supported per se in a Web application, the default behavior in a Web application is nearly identical from the end-user perspective. Consequently, likely this is not a feature of concern or one requiring further action on the part of the PowerBuilder developer.

To remove LiveScroll and other similarly benign features from view, the .NET Features Analyzer includes a convenient filter interface. The filter input mechanism is another TreeView DataWindow that can be exposed using the Options menu or the green arrow button at the right of the main window. The filter initially shows all of the features represented in the current unsupported features list as selected. To remove one specific feature from view, toggle the checkbox by clicking on the desired feature. To select or deselect groups of features (for instance, all Menu properties or every function, event, and property of a Tab control), use the context menu by right-clicking the desired element of the filter tree (see Figure 8). Changes to the filter take effect immediately, and the open tab views as well as the count of features displayed (shown directly above the filter TreeView) are updated accordingly.

For ease of use across multiple applications or perhaps when revisiting the features of a given application, you can also save the current filter selections via the context menu. When you save the filter, the items that are not selected are recorded in the INI file associated with the application (located by default in the user's local applications settings directory, e.g., C:\Documents and Settings\jsmith\Local Settings\Sybase\PowerBuilder 11.0). Since the filter setting is saved, you can reload the filter and apply it to any unsupported feature list that you subsequently load, thus giving you the option of universally ignoring specific features that you know will never be of interest regardless of the application you're working on.

While the hard work - namely implementing workarounds or alternative implementations for the more critical unsupported features - is still left up to you, the .NET Features Analyzer tool helps focus your efforts on the more important aspects of your applications. And since the utility is now in the open source domain on CodeXchange, customizing and extending the tools is only limited by your time and imagination!


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.