Home

	Expand Search

Release Bulletin PowerBuilder Enterprise 9.0

9. Migration information

9. Migration information

9.1 Migration Assistant

Before opening PBLs that were created in a previous release, use the Migration Assistant to check them for obsolete syntax or the use of new reserved words. To open the Migration Assistant, select File>New from the PowerBuilder menu bar and select Migration Assistant from the Tools page of the New dialog box.

9.2 Migrating from PowerBuilder 8

If you are using PBLs created using previous versions of PowerBuilder, you must migrate them to PowerBuilder 9.0. PBLs and PBTs should always be backed up before you migrate.

The Migrate Application dialog box might open automatically after you open a workspace that contains PowerScript targets built using PowerBuilder 8. You can also add a PBT containing such PBLs to an open workspace, or add PBLs built in an earlier version of PowerBuilder to a target's library list. If the Migrate Application dialog box does not open automatically, select each target that contains PBLs created using previous versions of PowerBuilder in the System Tree and select Migrate from the pop-up menu.

Web targets created in PowerBuilder 8 that use the Web DataWindow must be modified to use the HTMLGenerator90 component instead of the HTMLGenerator80 component. PowerBuilder 8 Web targets that do not use the Web DataWindow can be opened and deployed in PowerBuilder 9.0 without modifications. As a precaution, you should make backup copies of the target directories.

The format of PSR files created in PowerBuilder was changed in order to improve data integrity for the SaveAsAscii function. As a result, PSR files created in newer builds of PowerBuilder cannot be opened in builds that predate this change. This change was made in PowerBuilder 8.0 build 7063 and PowerBuilder 7.0.3 build 10102.

PowerBuilder 8 provided a direct connection to external SCC-compliant source control systems, and additional changes have been made in PowerBuilder 9.0.

Before migrating a source-controlled project from PowerBuilder 7 or earlier to PowerBuilder 9.0, read the chapter on using source control in the PowerBuilder User's Guide and the section on source control enhancements in the What's New Help.

Before migrating a source-controlled target from PowerBuilder 8, read the section on source control enhancements in the What's New Help.

Installing PowerBuilder 9.0 on the same machine as PowerBuilder 8 updates the registry entry for PBNative source control that is used by both versions of PowerBuilder. PowerBuilder 8 will subsequently use the PBNative DLL for PowerBuilder 9.0. You can reregister the PBNative DLL for PowerBuilder 8 at a command prompt by changing to the Sybase\Shared\PowerBuilder directory and entering the command

REGSVR32 PBNAT80.DLL

This also has the effect of changing the PBNative DLL for PowerBuilder 9.0. The only way to tell is that SCC revision numbers do not increment properly in the Library Painter list view after a check-in, and it will probably take longer to get out-of-sync status. You can reregister the correct PBNative DLL for PowerBuilder 9.0 by entering the command

REGSVR32 PBNAT90.DLL

If you uninstall PowerBuilder 8 from a machine where you have already installed PowerBuilder 9.0, the uninstall deletes the PBNative registry entry. Subsequently, if you want to use PBNative source control with PowerBuilder 9.0, you must reregister PBNAT90.DLL as described above. The uninstall for PowerBuilder 9.0 does not remove PBNAT90.DLL or the registry entry for PBNative source control. [CR 305789]

9.3 Migrating from PowerBuilder 7 or earlier

If you are using PBLs created using previous versions of PowerBuilder, you must migrate them to PowerBuilder 9.0. You should always back up PBLs before you migrate.

To add a target to your workspace that uses an application built in PowerBuilder 7 or earlier, use the Existing Application Target wizard on the Target page of the New dialog box. After you complete the wizard, the Migrate Application dialog box opens, allowing you to migrate the application to PowerBuilder 9.0. For information about using workspaces and targets, see Chapter 1 in the PowerBuilder User's Guide.

New reserved words were added to the PowerScript language in PowerBuilder 8 to support exception handling. If you use any of the new reserved words (TRY, CATCH, FINALLY, THROW, and THROWS) as identifiers in existing applications, you must change these identifiers, giving them nonconflicting names. You can run the Migration Assistant, available on the Tool tab page in the New dialog box, to locate incorrect use of the new reserved words.

The Transport object and its associated properties and methods are obsolete in PowerBuilder 8 and later and have been removed from PowerBuilder 9.0. This object was used for distributed PowerBuilder applications. Additional properties and methods that were used for distributed PowerBuilder and are therefore obsolete include:

• ConnectionBegin and ConnectionEnd events on the Application object

• GetServerInfo, RemoteStopConnection, and RemoteStopListening functions on the Connection object

• SetConnect function for proxy objects

• ConnectString and Trace properties on the Connection object

• ConnectionInfo structure

The JavaBeans Proxy and Web.PB generators were also used with distributed PowerBuilder applications and have been removed.

In PowerBuilder 7 or earlier, if an error occurs that is not caught by an Error or ExternalException event, the application's SystemError event is triggered immediately. If there is no code associated with the SystemError event, the application is terminated. Otherwise, after the SystemError event executes, control returns to the location in the code where the error occurred.

In PowerBuilder 8 and later, if an error occurs that is not caught by the exception handling mechanism or by an Error or ExternalException event, the script terminates and the call stack is unwound. If the error occurs as the result of a Triggerevent call in a script, the calling script terminates and the call stack is unwound. In most cases, the SystemError event is not triggered until the call stack becomes empty. If an event of a response window caused the error, the SystemError event is triggered as soon as the response window event completes.

Because of this change in behavior, code that follows the statement that caused the error is not executed after the SystemError event is fired, as it would have been in previous releases. This change has a major impact on applications that rely on the previous behavior of returning control to the script where the error occurred. Code that relies on this behavior must be modified in PowerBuilder 8 and later.

You can handle potential errors by wrapping code that might cause an error in a try-catch block to prevent the SystemError event from being triggered when an execution error occurs. It is still advisable to code the SystemError event to handle any uncaught exceptions. You should not allow the application to continue after the SystemError event is invoked. The SystemError event should clean up and halt the application.

The IsValid function now returns false if passed an argument of type Any that cannot be converted to a PowerObject. In PowerBuilder 7 and earlier, passing an invalid object to IsValid caused a system error. You should also take note of the SystemError event change described in the previous section.

You can specify custom colors for each component of graphical table representations in the Database or SQL Select painter by selecting Design>Options>Object Colors. The colors you specify are saved in your PB.INI file in the [Database] section. The format in which these colors are stored changed in PowerBuilder 8 and later to support the increased number of Windows system colors and custom colors available for controls. For example, these are color definitions for lines representing keys in a PowerBuilder 7 PB.INI:

ForeignKeyLineColor=0 0 255
IndexKeyLineColor=255 0 0
PrimaryKeyLineColor=0 128 0

These are the corresponding entries in a PowerBuilder 8 or later PB.INI:

ForeignKeyLineColor=16711680
IndexKeyLineColor=255
PrimaryKeyLineColor=32768

You might have used workarounds to solve problems with Netscape rendering in releases prior to PowerBuilder 7.0.2 C3. Some of these workarounds might not work correctly in this release because of improvements to Netscape rendering.

Specifically, if you used computed fields or text fields containing only spaces, the Web DataWindow generator now creates a table entry for these fields, making the table display twice as wide. If you see this behavior, delete these placeholder fields and use a more standard layout.

9.4 Migrating from PowerBuilder 6.5 or earlier

In PowerBuilder 7 and later, every object in a DataWindow object must have a name. During migration, objects without names are assigned names based on the user-definable prefix settings, usually dw_1, dw_2, and so on. Names are assigned sequentially, therefore an object might be assigned a name already used by another object in the DataWindow object. This can cause unexpected behavior. For example, naming an unnamed report to a name already used for another DataWindow object, such as dw_2, could cause a Getchild/Sharedata or GetChild/Retrieve operation to find and use the wrong DataWindow object.

To work around this problem, select Design>Options in the DataWindow painter and modify the DataWindow object prefix on the Prefixes tab before migrating. After the DataWindow object has been migrated, the prefix can be changed back.

A window no longer inherits its icon from the application that contains the window. To use the application icon, you must explicitly assign it to the window after migration using the new enumerated value AppIcon!.

PowerBuilder 7 and later use Microsoft ListView and TreeView controls. As a result, you might see some changes in behavior that require you to remap some events. When you perform mouse actions, some events do not fire, and some fire in a different order from previous releases.

TreeView

In PowerBuilder 7 and later, the pbm_rbuttonup event does not fire, but is immediately followed by a pbm_tvnrclicked event (the stock RightClicked! event for a TreeView). Therefore, you can copy any code from pbm_rbuttonup to RightClicked! or have the RightClicked! event trigger whatever code exists in the pbm_rbuttonup. If you trigger the code, keep in mind that in PowerBuilder 6 both pbm_rbuttonup and pbm_tvnrclicked fire. To make this code work in PowerBuilder 6 as well as 7 or later, you should make sure the code is executed only once in PowerBuilder 6. For example, you could set a boolean variable in pbm_rbuttonup that prevents the code in pbm_tvnrclicked from executing if the variable is true. You would then reset the variable to false at the end of pbm_tvnrclicked.

Additionally, in PowerBuilder 7 and later, using the right mouse button to select a previously unselected TreeView item causes the previous TreeView item to regain focus when the button is released. In PowerBuilder 6, using the right mouse button to select a TreeView item caused it to become permanently selected. To duplicate this behavior in PowerBuilder 7 and later, place the line of code

this.SelectItem(handle)

In PowerBuilder 7 and later, the pbm_tvnrdoubleclick event (the stock RightDoubleClicked! event) does not fire but is immediately preceded by a pbm_rbuttondblclk event. Therefore, you can copy any code from the RightDoubleClicked! event to the pbm_rbuttondblclk event or have the pbm_rbuttondblclk event trigger existing code in the RightDoubleClicked! event. Both events fire in PowerBuilder 6, so you need to use a technique similar to that described above to achieve version-independent code.

ListView

In PowerBuilder 7 and later, the pbm_rbuttonup event does not fire if you use right-click on a specific ListView item, but it does fire if you right-click in the white area of the ListView where there are no items. A new event, pbm_contextmenu, always fires when the right mouse button is released. Table 1 shows when events are fired in PowerBuilder 7 and later.

You should place code that should be executed when an item is actually selected by the right mouse button in the pbm_contextmenu event. This is how PFC ListView objects work in PowerBuilder 7 and later. The code that you want executed when the right mouse button is released on the white area of the ListView should remain in the pbm_rbuttonup event. Because pbm_contextmenu is called twice when you right-click in the white area, you should put code in the RightClicked event to retain the index of the item that was selected. If no item is selected, then the index value will be zero and you should use that as a test in the pbm_contextmenu code to decide whether that code should be executed.

The following example assumes that you have declared a private instance variable of a TreeView standard class user object called ii_item. This statement is in the Clicked! event script:

ii_item = index

The pbm_rbuttonup event script should contain code to be executed when the right mouse button is released after being pressed in the ListView but not on an item in that ListView.

The pbm_contextmenu event script should contain code like the following:

IF ii_item > 0 THEN
   // code to be executed when the right mouse
   // button is released after being pressed on an
   // item in the ListView
END IF