My list of preferred new PowerBuilder features

Now that Appeon is handing development and distribution of PowerBuilder, they're requesting input from the customer base on the new features we would like to see.  If you haven't provided that input, you should do so soon at http://www.appeon.com/future

That said, here's my list.  I didn't actually submit them all to Appeon, as I didn't think about some of them until after I did my original submission.  But this gives me a chance to explain the rationale behind why I think they're important and solicit feedback on them.

Update Current Functionality

Add the WCF client functionality in PowerBuilder.Net to PowerBuilder Classic.  The current web service client functionality in PowerBuilder Classic is based on ASP.Net Web Services, which is significantly outdated.

Add the REST client functionality in PowerBuilder.Net to PowerBuilder Classic.  While SOAP remains popular in the enterprise, there is a need for REST as well in the enterprise, and it is quite popular in the consumer space.

Update the OData version support in PowerBuilder Classic to 4.0.  The current implementation, only supports version 2.0, which is significantly out of date.  Note that because the current implementation is based on WCF Data Services, a different approach will be needed to support 4.0 and later, as Microsoft will not be supporting 4.0 and later through WCF Data Services.

Update database drivers to support the functionality in the latest versions of the databases.  When SAP released PowerBuilder 12.6, they indicated that the new features included support for Oracle 12c and MS SQL Server 2012.  Microsoft has since released MS SQL Server 2014.  In addition, the "support" for Oracle 12c did not include support for important new features in that version such as 32K VARCHAR2 columns, identity columns, implicit result sets,  row offset and row limit clauses or binding to pl/sql types and booleans.

Near Term Enhancements

Provide a native method of printing to PDF (something that doesn't require Ghostscript or FOP).  The current methods used to print to PDF require too much administrative effort during deployment.  Because of the GPL license requirements of Ghostscript, users have to download and install it themselves.  Alternatively, the XSL-FOP method requires the deployment of a JRE, and only supports a subset of the available DataWindow styles.  We need a method of printing to PDF that supports all DataWindow styles and doesn't require additional deployment steps.

Add DataWindow filtering and sorting capability similar to PowerFilter.  Excel like sorting and filtering options are pretty much standard in grid controls today, but can only be implemented in the DataWindow through that add-on product.

Add modern controls such as the Windows Style Bar available in the PowerBuilder Ultimate Suite.  The controls currently available in PowerBuilder are reminiscent of Windows 95.  We need up to date user interface controls in order to develop applications that look modern.

I'm a bit conflicted over those last 3 items.  I'd like to recommend enhancements that would compel existing customers to upgrade.  I selected those 3 because they are examples of where my own shop thought the capability was important enough that we used third-party controls to achieve them.  My rationale is that other shops are like mine and would find such capability important and would therefore find the upgrade compelling.  There are two issues with that.

1.  Other shops, like mine, may have also already obtained third party products to implement the capability.  If so, then adding that capability to PowerBuilder would not provide those shops with a compelling reason to upgrade.  That would be because there would be little reason to rewrite the app to use the native functionality rather than the third party control.

2.  Implementing such capability in the product cannibalizes what is left of the PowerBuilder third party ecosystem.

Longer Term Enhancements

Move all of the supported targets into a single, modern IDE.  One of the reasons that PowerBuilder.Net was developed was not just to introduce new .Net targets, but also to start the movement to a state-of-the-art IDE.  It was thought that instead of trying to add modern IDE features to the existing Classic IDE, the Classic targets would eventually be added to the PowerBuilder.Net IDE as well.  Doing so would leverage the work that Microsoft was doing keeping that IDE modern and allow the resources that were maintaining the Classic IDE to be redirected too other enhancements.  The PowerBuilder.Net IDE though has met with lukewarm reception, largely to issues with the WPF target that was the main target in that IDE.  There are issues with the isolated Visual Studio shell that is is based on as well.  That shell has complicated the install process (particularly if some version of Visual Studio was already on the machine) and Microsoft seems to be doing a complete rewrite of it with each new version of Visual Studio.  I would still like to have modern IDE features for PowerBuilder Classic development, but I'm thinking that using the Visual Studio isolated shell might not be the best approach.  Perhaps Eclipse should be considered instead.  I use a number of products based on that IDE (Eclipse itself for java development, Adobe Flash Builder for Flex development and Actuate BIRT Designer Pro - a BI tool) and have had no problems with install or conflicts between the products.  And Eclipse doesn't seem to require a complete rewrite of add-ins whenever they do a new major release.

Add a wizard to make non-visual .Net assemblies available to PowerBuilder Classic through COM Callable Wrappers (CCW).  The use of non-visual .Net assemblies through CCWs is is something I've been promoting since 2006.  At the NCPBUG conference earlier this month I notice that a couple of other sessions at that conference other than mine own recommended it as well.  Accessing non-visual assemblies via conditional code blocks was added to the WinForms target, PowerBuilder Classic .Net assembly target and the now-defunct WebForm target.  However, those target types have not turned out to be popular, and there are significant limitations to the conditional code block implementation (e.g., no Autoscript, a language that is neither PowerScript or C# but something in between, and scripting errors only reported during compilation).  The CCW approach makes non-visual .Net assemblies accessible to PowerBuilder Classic targets.  However, it is also currently somewhat complicated to use.  It either involves administrator rights for deployment (in order to add assemblies to the global assembly cache and registry changes) or the configuration of manifest files to allow for side-by-side deployment.  A wizard could make this excellent method of extending PowerBuilder Classic available without significant effort.

Add a wizard to make visual .Net controls available to PowerBuilder Classic.  I've been advocating this approach for enhancing PowerBuilder Classic since 2007 using the .Net Interop Forms Toolkit, which Microsoft has released as open source.  That's not the only method that can be used to accomplish this, but it's one that's fairly easy to use and readily accessible.  However, as above, deployment can be an issue.  The use of the interop forms toolkit also requires the use of a third party IDE.  In addition to addressing the deployment issues, I would anticipate that this wizard would utilize a designer within the PowerBuilder Classic IDE.

Add a C# user object painter.  Essentially doing the same thing for non-visual assemblies as the last enhancement for visual controls.  Back in the PowerBuilder 6.0 days, there was a C++ user object painter build into PowerBuilder.  I envision the C# user object painter doing much the same thing.  Allowing a developer to code some functionality directly in C#, and then compiling it as an assembly exposed via a CCW used directly in PowerBuilder Classic code.