In addition to the other new features in PowerBuilder 10.5 that we've covered in this issue, there are a number that do bear mentioning but aren't significant enough to merit a separate article. I've grouped them together in this "miscellaneous" enhancements discussion. I'm going to look at a few of those, pretty much in alphabetical order.

Autosize Height for All Bands
One of the enhancement requests that has probably been on the list as long as PowerBuilder has been around is for the auto-height capability on bands other than the detail band. Well, that's finally arrived. PowerBuilder 10.5 adds a new autosize height property to all bands of the DataWindow (see Figure 1). Note in this particular sample that the Department columns (including a new autosize height Dept Text long text column) are in the group header band in this DataWindow. The script to create this new column and populate it with large blocks of text is provided in Listing 1. In addition, the column headers at the bottom of the group header have their slide-above property enabled so they can move as the long text column expands.

When the DataWindow is previewed, you can see how the group header band expands to accommodate the large text block (see Figure 2).

In addition, the property is now modifiable at runtime via a Modify command. In the sample, I allow you to toggle the AutoSize for the group header band as follows:

string ls_autosize
ls_autosize = dw_1.Describe ( "DataWindow.header.1.height.autosize" )
CHOOSE CASE ls_autosize
    CASE 'yes'
      dw_1.Modify ( "DataWindow.header.1.height.autosize = 'No'" )
    CASE 'no'
      dw_1.Modify ( "DataWindow.header.1.height.autosize = 'Yes'" )
END CHOOSE

Byte Data Type
The byte data type is an integer value from 0 to 255. The new data type adds increased functionality in a number of areas. Both Java and C# have byte data types, so that particular data type is important for interoperability. Many databases also either have a byte data type or a data type in that range (e.g., the tinyint data type in Adaptive SQL Anywhere).

Another area where it is particularly important is interfacing with the Windows API. Up through PowerBuilder 9.0, the char data type was essentially synonymous with the byte data type because in an ANSI environment a char is a single byte. That meant that any time a byte field was specified in a Windows API call, a char could be used instead. That all changed with Unicode support in PowerBuilder 10. A Unicode char is two bytes, and so the mapping of a char for a byte that worked so well in previous versions suddenly broke.

With the introduction of the byte data type, it's not only possible to make those calls now, but to make them with a data type more representative of the underlying data. With the char mapping, you still have to convert the data from a char to an integer data type. With the byte data type, no conversion is needed anymore.

We're going to look at implementing a Windows API call to demonstrate the use of the new byte data type. PowerBuilder provides a number of system functions that implement the Microsoft Common Dialogs Control (e.g., File Open, File Save, Setup Printer, Choose Color, etc.). One that PowerBuilder does not implement is the Choose Font dialog (see Figure 3). That dialog is invoked through the ChooseFont Windows API call, which takes a CHOOSEFONT structure as an argument. One of the attributes of the CHOOSEFONT structure is a pointer to a LOGFONT structure, and many of the attributes of the LOGFONT structure (e.g., italic, underline, etc.) are byte values, which is where the new byte data type comes in.

We'll need to declare a local external function reference for the ChooseFont Windows API call and some additional Windows API calls used to manage memory during the call (see Listing 2). We'll also need PowerBuilder structure definitions for the LOGFONT (see Listing 3) and CHOOSEFONT (see Listing 4) structures. We then call the function using the code from Listing 5.

DatePicker Control
The DatePicker control (see Figure 4) provides a native dropdown calendar, similar to what's implemented in PFC. It also implements a TimePicker control as a spinner (not a dropdown) if the underlying data type is time, the format is a time format, and the ShowUpDown property is enabled on the General properties (see Figure 6). Other General properties include the format for the date in the non-dropdown portion of the control and include the capability to provide a custom format. The Calendar properties (see Figure 5) determine which day of the week the dropdown calendar starts on, whether there is a Today section on the bottom of the dropdown, whether the current date is highlighted, whether week numbers are included, and the colors and font for the dropdown.

The DataWindow already supported a TimePicker edit mask by setting the spin control attribute (see Figure 8). Added in PowerBuilder 10.5 is the dropdown Calendar option for a date edit mask (see Figure 7).

PBNI Changes
A couple of issues with PBNI extensions have been addressed in this release. Until this release, each PBNI extension required the creation of a wrapper PBD file. If you use a number of such extensions, your library search path could be unnecessarily long. In addition, you need to deploy not only the extension, but all those wrapper PBDs. Furthermore, some build utilities could be confused by such wrapper files and not handle them correctly (such as attempting to optimize or regenerate them). Further still, it was not possible to source code control the individual components in the PBD. Instead, the entire PBD had to be source controlled separately using the source control systems utilities, rather than through the PowerBuilder IDE.

PowerBuilder 10.5 adds the capability to "import" the PBNI extensions directly from the DLL or PBX file into an existing PBL (including the PBNI system extensions supplied with PowerBuilder such as SoapConnection or PBDOM). This means the PBD files are no longer required at development, no longer have to be deployed, and can't confuse build systems or require registration with source control systems.

To import the PBNI extension, right-click on the PBL you want to import them into and select the new "Import PB Extension..." menu option (see Figure 9). After selecting the PBNI extension file, PowerBuilder "imports" (creates wrapper objects for) all of the objects and functions from the extension file. If you don't require all of them, simply delete the wrapper objects back out of the PBL that you don't need. The syntax for such a wrapper object is shown in Listing 6. It contains a reference to the extension file (which still needs to be deployed), the object name, and the methods it exports. Note that it's pretty standard PowerBuilder code, but there is a "native <extensionfilename>" suffix on the declaration of the object that indicates that it's a wrapper for a PBNI extension.

Conclusion
The list could go on and on. For example, there is a new "Suppress group headers on page breaks" option shown in Figure 1 that we haven't touched on. I'm sure we'll cover more of them in future issues of PBDJ.