Just over a year ago PowerBuilder 10.5 was about to release and we looked at the top 10.5 reasons to move to that version. In that same vein, I'm going to look at the top 11 reasons to consider PowerBuilder 11.0, which is just about to hit the street. This time I'm going to break those reasons into two groups: those that directly affect your end users (things they will notice) and thing that will make your life as a developer easier but won't necessarily affect your users. The reason I want to focus on them that way is because as developers we often get excited about the second set, but in order to sell an upgrade to our managers we often need to stress the former.

Obviously this isn't a comprehensive list of the new features in this version. There are quite a few others such as window animation and transparency, and database drivers. I'm focusing on a limited set that I consider to be the most important or those that may generate the most interest. First, the new features that directly affect your users.

1)  .NET WebForm Target
This feature may be the one that is most highly touted for this release. It enables you to take an existing Windows application (even an MDI application), and with few, if any, changes deploy them as browser-based .NET WebForm applications. For people who want to take existing applications and move them to the Web without losing a great deal of the rich client capabilities, this is an attractive feature.

2)  .NET WinForm target - Smart Client
A .NET WinForm target allows you to take an existing application and deploy it as a .NET WinForm application (essentially a standard Windows application) but one that can be distributed and automatically updated through a browser. A Smart Client application runs within an isolated "sandbox" when deployed to the client. It accomplishes the minimal footprint of a browser-based application but provides the full rich client support of a standard Windows application.

3)  UseEllipses DataWindow Property
I don't know about your applications, but I have a number in which there are characters fields that allow for many times more data than is typically entered. For example, a company name field might be 120 characters long because of the one or two cases where we need to support a really long company name. (For example, the Wall Street Journal Law Blog reports interviewing a law firm with the name of Ziffren, Brittenham, Branca, Fischer, Gilbert-Lurie, Stiffelman, Cook, Johnson, Lande & Wolf.) The question is, how many characters do you show to the user when the average company name is 30 characters; and what do you do if you only show 30 when the 120 character monster shows up? Enter the UseEllipses DataWindow property. When the field is not in focus and the text exceeds the width of the field, ellipses are shown to make it obvious to the user that there is more text than what is visible.

That's it for the end-user impacting ones. Not that there aren't more, but I found the developer-focused enhancements more interesting than the others. So, without further ado, here they are:

4)  ASP.NET Web Service Target / .NET Assembly Target
I almost put this under the end-user impacting, because it can affect them indirectly. These two options really expand your capability for the reuse of your existing PowerBuilder code. If you're in a heterogeneous shop (one that uses a number of development tools, particularly some .NET IDE and PowerBuilder), these two target types allow you as a PowerBuilder developer to make your PowerBuilder components available to the .NET developers (and Java developers in the case of Web services) for reuse in their applications. Your end users might see the application rehosted with a different user GUI, but the business logic would continue to be PowerBuilder based.

5)  .NET WinForm Target - Conditional Compilation / .NET Assembly Import
In addition to the .NET targets already discussed, one of the things you can do with this new release is recompile your typical PowerBuilder client/server application as a standard WinForm application. But the question - if you aren't compiling as a Smart Client - is why? Compiling to a WinForm target has some of the same long compile types and regression testing to ensure that it behaves the same as the p-code issues that machine-code compiles with the current versions of PowerBuilder have. Those issues are what have most folks avoiding machine-code compilation as if it was a root canal without anesthesia.

The answer is the .NET assembly import and conditional compilation features. The .NET assembly import means that PowerBuilder developers can import .NET framework assemblies or private assemblies and then use them within PowerScript code. It's the inverse of creating a .NET assembly target above. Now you can incorporate the assemblies that the .NET developers have created in your PowerBuilder application.

The conditional compilation feature means that you can add such calls to your existing code, but surrounded by blocks that ensure that they only get called if deployed to a .NET target. That is, your typical p-code compile would simply ignore the reference to the assemblies and continue to behave as it always had.

In a sense, it's similar to PBNI, which gave us the ability to incorporate C++ classes as if they were PowerBuilder objects within our applications. However, it's also a whole new level beyond that. The entire .NET Framework becomes available immediately (which is quite extensive), so do any .NET assemblies that were compiled to allow reuse. Unlike, PBNI, there's nothing special you have to do to make sure PowerBuilder can access the code. And finally, it's several order of magnitudes easier to write script that utilizes .NET classes than to code a PBNI extension.

There are some unfortunate aspects though. This particular feature would have been even more incredibly useful if it could also be supported in p-code compiles (a true Interop implementation). In addition, doing development for any of the .NET target types can be a bit painful because .NET targets don't currently support incremental recompiles. That latter deficiency is supposed to be in the plans for a later release.

6)  DataWindow Web Service Data Source
So you've found that great Web service and you want to display the results in a DataWindow. Until PowerBuilder 11 that meant you would need to create a proxy for it, import the SoapConnection and SoapException objects from the Sybase-supplied PBNI extension, create a script to call it, parse the results into a string or structure, and then import that into the DataWindow. With PowerBuilder 11 it just got a whole lot easier. You just point the DataWindow painter at the Web service, and it creates a DataWindow based directly on the return from the Web service. No coding! In fact, you can point the newly created DataWindow object to Web services to do the updates as well.

7)  Remember DataWindow Retrieval Arguments
This has to be one of the number one enhancement requests for some time. Not one of those ground-shaking new features, just something that will save you a ton of time when debugging and testing your application. It certainly drives me nuts when I've got a DataWindow that's got a bazillion retrieval arguments and I have to keep re-entering them every time I want to preview the DataWindow.

8)  System Tree Enhancements
The system tree now includes a script icon to indicate which functions and events are coded on the object. In addition, double-clicking on the event or function in the system tree opens the object to that event/function in the painter. Finally, if you've imported any .NET assemblies, they appear in the System Tree and you can browse either classes or methods.

9)  Break into Debugger Upon Exception
You can indicate, on an exception class basis, whether the debugger or your code's own exception handling gets the first chance at any raised exceptions. If you select the debugger, a dialog appears when that class of exception occurs, which allows you to select whether you want to continue into the debugger or return processing to the application code.

10)  Output Window Enhancements
I don't know about you, but it drives me nuts when I do a search and it scrolls my last build information a few pages up in the output pane, or I do a compile and lose my search results. Well, no more. The output pane has finally been split up according to the type of information: default (build messages), debug, errors, warnings, search, and (for .NET deploys only) unsupported features.

11)  Resizable Dialogs
If you work with real long paths to your source code, many of the dialogs in prior versions of PowerBuilder were aggravating because they weren't resizable and in some cases wouldn't allow you to scroll to see full path names. In PowerBuilder 11, all of the dialogs within the IDE are resizable. If you have long path names, simply widen the dialog until you can see the entire path in a single glance.

Well, those are my 11 choices. By the size of the text above and the number of items, you might think that the non end-user enhancements outweigh the end-user impacting items. Numerically, perhaps they do, but it would be hard to overstate the magnitude of the significance of the .NET targets. For some, this will mean that their PB-to-the-Web solution has finally arrived. For others, they will find that a smart client deploy gives the full capabilities of both a rich client and browser-based implementation. For still others, they will still do standard client deploys, but a whole new world of .NET functionality can now be incorporated.