26 April 2018
Development, Appeon, Engagement Profiles
By John StranoSenior Consultant
A recent project required Intertech to migrate and update a customer’s PowerBuilder 5.0 application to PowerBuilder 12.6. The application in question had been developed for one of our aerospace clients. The customer wanted 1) to prepare for the future by migrating their application to a version that would be supported by Appeon and 2) additionally “modernize” the User Experience (UX) so that their product looked and felt contemporary running alongside their customer’s other applications.
With the recent release of Appeon PowerBuilder 2017, enterprises are looking to have their mission-critical PowerBuilder applications running under a supported version of PowerBuilder, and that their applications are “modernized” so their mission critical assets are ready to move into the future with a modern User Experience (UX).
The level of effort to upgrade any PowerBuilder application is influenced by two factors: the version of PowerBuilder the app is being upgraded from and the features of PowerBuilder the app utilizes. Appeon PowerBuilder 2017 was based upon the PowerBuilder 12.6 release. By upgrading your PowerBuilder application to v12.6, issues moving from v12.6 to v2017 should be negligible, but moving from PowerBuilder 5.0 can be a bit more challenging.
THE MIGRATIONA PowerBuilder v5.0 to v12.6 migration brings to mind a roster of checkpoints to verify when bringing a Win95-era application forward.
• Unicode v. ANSI String Utilization• DDE• OLE• OCX/ActiveX• 16bit external resources
This list is by no means comprehensive. For instance, another recent migration effort entailed a need to re-examine and modify an approach to dynamic menu assignment and manipulation.
Our candidate PowerBuilder 5 application had been developed for and was run under Windows 95 and needed to be upgraded to PowerBuilder 12.6 to be run in a Windows 7 64-bit environment.
Unicode v. ANSI String Utilization
The application pre-dated PowerBuilder v10 where all strings in PowerBuilder are Unicode/DBCS by default. This required looking to any part of the implementation that assumed any strings to be ANSI and modifying those implementations to use Unicode. We also had to examine all external function calls for arguments or return values of the string data type; anywhere within the method signature paying special attention to strings passed by reference:• Unicode support in PowerBuilder• Unicode String versus ANSI String (PB10)Our candidate PowerBuilder 5 application had only a few ANSI-to-Unicode issues.
DDE or Dynamic Data ExchangeDDE is a technology for enabling PowerBuilder applications to communicate with other windows applications. DDE is fairly old and predates OLE as an inter-application protocol. Issues surrounding the migration of DDE are primarily concerned with the version of the DDE partner your PowerBuilder app is communicating with and the version of Windows in which the two DDE partners are running. Our candidate PowerBuilder 5 application did not use DDE.About Dynamic Data ExchangeAbout DDE
OLE or Object Linking and EmbeddingOLE is another technology for enabling PowerBuilder applications to communicate with non-PowerBuilder-implemented applications. Issues surrounding the use of OLE have less to do with the version of Windows in which the applications are running and more to do with the version of your OLE partner application and that version’s level of adherence to the OLE specification. Our candidate PowerBuilder 5 application did have one OLE item.Using OLE in an Application
OCX/ActiveXOur client’s PowerBuilder 5 application used an ActiveX/OCX control to visualize data as graphs. We experienced a certain amount of trepidation once this 30-year-old 3rd party component was discovered in the application. In those days there was a burgeoning marketplace for controls that were developed utilizing the ActiveX/OCX flavor of OLE. PowerBuilder 5 saw PowerSoft partnering with Tidestone (formerly Visual Components) who had developed best of breed controls like Formula One, a spreadsheet control called First Impression and a graph control. A search online resulted in no sign of Tidestone as an active business entity and no sign of any firm that might have acquired Tidestone’s assets let alone still supported them. Our candidate PowerBuilder 5 application used Tidestone’s First Impression OCX.
Once the PowerBuilder 5 libraries were successfully migrated to v12.6, the first portion of the application tested was that utilizing First Impression. It ran…successfully. Moreover, the installation utility we used the package the application was successfully able to extract COM data from the First Impression library and successfully register the component/control on target Windows 7 64 bit workstations. We had been prepared to have to “go shopping” for a more contemporary graph control equivalent with the accompanying cost of purchase and code modification. As it turned out, no code modification to our candidate PowerBuilder 5 application was necessary.Programming the ActiveX control
16 bit External ResourcesReleased to run under 32 bit Windows 95, PowerBuilder 5 still needed to run under Windows 3.1 and v3.11, which was 16 bit. 16 bit! How long before our PowerBuilder applications need to run in a 128 bit OS? The PowerBuilder 5 version of the PFC had its two “platform” service NVOs, one for 16 bit, one for 32 bit; the class that was instantiated was determined at runtime by detecting the variant of OS environment on which the app was running. Undesirable anecdotal accounts of applications that relied upon external functions calling 16 bit DLLs which would not run under latter day OSs and for which the source code had been lost. Our candidate PowerBuilder 5 application did not use any 16 bit resources.Microsoft Windows versions
Using the Original PFCSince the candidate PowerBuilder 5 application was PFC-based, we had to determine whether one or more PFE objects had been customized. Indeed, it was a best practice to constrain any customizations/extensions to the framework and its service-based architecture to one or more of the PFE layers and prohibit changes from being placed in the PFC ancestor layer.
For a concise discussion of utilizing the PFE v. PFC layer of the framework, take advantage of Terry Voth’s entry at15-Minute PFC Learning Curve
THE MODERNIZATIONIn the era this application was originally developed, enterprise-class mission-critical applications were used by a work force that had no experience with the Web. Before the advent of the Web and the “richer” UIs of browser-based interfaces, Users perceived the gunmetal gray Windows 95-esque interfaces as cutting edge.
Users of line of business applications are now used to enhanced graphics; even in their spare time as they browsed the Web. Gone were the days of Win95 UIs appearing to be head-and-shoulders above the green or amber phosphor screens of their progenitors’ mainframe terminals. Like it or not, business owners of applications began to perceive any application whose UI seemed dated, began to perceive those applications as outdated, outmoded and less capable than apps with a richer UX…even with evidence to the contrary.
Likewise, this 1990s-generation development team had built this PowerBuilder 5 application with the Windows 95 look and feel. Our client was concerned that the business owner would find the application to be dated unless we worked to “modernize” the UI and thereby enhance the UX as well. Given a limited budget, we went for visual modifications that had the most “bang for the buck”. We took five steps to provide what would most improve the subjective UX with the balance of time left after the functional upgrade:
• Modify the fonts used to be those perceived to be more contemporary• Change the default background colors, primarily the Win 95 gunmetal gray.• Employ contemporary PowerBuilder menu enhancements• Use modern fonts, icons and gradients.• Use multilevel icons for TreeViewItems, also used alternatives for different TreeViewItem “states” which was not previously utilized in this app• Utilize the PFC window resize service
Certainly, these are not all the possible measures PowerBuilder developers may take to enhance the UX of their applications. We mean here to feature those now-possible modifications that took only a modicum of time to employ, but would derive the greatest perceived enhancement/refreshment.
Font Choice and Background Color Choice
The application’s login window depicted here illustrates our initial steps in UX modernization: font update and background color modification.
We substituted the font “Segoe UI” for “MS Sans Serif” throughout the application, and with few exceptions “ButtonFace” was comprehensively substituted for “Silver” as the background color of choice. As a side note, you’ll see that we removed the use of hardcoded path names from the image file name specification.
After PowerBuilder 10.5 a wealth of visual enhancements was open to the developer. One of the major capability enhancements has been to the menus and their associated toolbars. You’ll note the somewhat nostalgic use of the default icon library in the PowerBuilder 5 incarnation. As a prelude to implementing these so-called “contemporary” menu/toolbar options, we “went shopping” for icons that were more intuitive for this process engineering application. The icons found had a pleasingly Spartan monochromatic palette that lent itself to the constructivist look and feel of this engineering-centric app.
In addition to the use of color gradient use for the toolbar, you’ll note that gradients were implemented (BitMapGradient) for behind the icons on the dropdown menu (MenuBitMaps) as well. Note the use of MenuTitles with their 90 degree escapement and the choice to use TitleGradients behind those titles.
TreeView Control Icons
While this feature was available with the release of PowerBuilder 5, it hadn’t been implemented in our candidate application. This TreeView control utilized only two levels but even so the visual aspect of the icons, especially designating separate icon for each level’s Selected state, increased the appeal of the UX and as with any adequate UX, it was less visually taxing for the Users over a protracted session of use.
PFC Windows Resize Service
While this feature was also available with the release of PowerBuilder 5 and the PowerBuilder Foundation Class (PFC), it hadn’t been implemented in our candidate application. We used the Service in order to take advantage of the additional screen area that is now available for display. The candidate application had been constrained by screen resolutions of the Windows 95 era. Due to time and budget constraints, we did not implement the PFC DataWindow Resize Service, but the UX could have been incrementally enhanced with this feature as well.
It’s Not Legacy – It’s Heritage
These seemingly minor modifications have had a cumulative effect to give the application a subjective refresh for the User Experience of this mission-critical application. The perception of this application as outmoded due to its outdated appearance has been allayed. This refresh/modernization now has had the UX reach parity with the reliable functionality and performance that reflects why this tried-and-true, PowerBuilder-developed asset has served its User base so well.
Moreover, options for this application and those like it are now preserved. Should the business owner need to consider browser-enabling the application with Appeon Web or mobilizing it with Appeon Mobile, those capabilities are available for expanding the scope of already-valuable assets.