je copie le texte ici au cas où la page ne serait plus online

Sybase a écrit:

Migrating PowerBuilder Applications

You can migrate a PowerBuilder application from any version of PowerBuilder directly to any later version. Before you migrate to a later version, read this document to learn about changes in PowerBuilder that might affect your application.

This document addresses changes between PowerBuilder 6.5 and PowerBuilder 11.1. Read all sections that apply to your application. Subsections with IM in parentheses after their titles also apply to InfoMaker.
1 Migrating from any PowerBuilder version
2 Migrating from PowerBuilder 10.5 or earlier
3 Migrating from PowerBuilder 10 or earlier
4 Migrating from PowerBuilder 9 or earlier
5 Migrating from PowerBuilder 8 or earlier
6 Migrating from PowerBuilder 7 or earlier
7 Migrating from PowerBuilder 6.5 or earlier

1 Migrating from any PowerBuilder version

1.1 Migration Assistant

Before opening PBLs that were created in an earlier version, use the Migration Assistant in the new version 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.

1.2 Migrating PBLs

You must migrate PBLs created with earlier versions of PowerBuilder to the new version. You should always back up PBLs and PBTs before you migrate.

The Migrate Application dialog box opens automatically after you open a workspace that contains PowerScript targets built using an earlier version. If you 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, the Migrate Application dialog box does not open automatically. To open the dialog box, select each target that contains PBLs created using earlier versions of PowerBuilder in the System Tree and select Migrate from the pop-up menu.

Please read the section on migrating targets in the PowerBuilder User's Guide before migrating your applications.

1.3 Migrating database profiles (IM)

To use database profiles that were set up in an earlier version of PowerBuilder, right-click any item in the Database Profiles dialog box in the earlier version of PowerBuilder and select Export Profile(s) from the pop-up menu. You can then import the profiles you select in the Database profiles dialog box in the later version of PowerBuilder.

1.4 Runtime DLLs (IM)

The applications that you build using any version of PowerBuilder should be deployed with the PowerBuilder runtime DLLs from the same version. If the development computer is updated with a new build, PowerBuilder .NET applications and components must be rebuilt and redeployed with the new runtime files.

2. Migrating from PowerBuilder 10.5 or earlier

2.1 Migrating EAServer targets

In PowerBuilder 11, the EAServer Component target wizard creates a specialized EAServer target instead of an Application target. After you migrate an existing EAServer target to PowerBuilder 11, you cannot start the remote debugger to debug the target unless you open the Project painter and select the Debug menu or toolbar item, or select Debug from the project?s pop-up menu in the System Tree. To ensure that your target behaves correctly, you should use the EAServer Component target wizard to create a new EAServer target, select ?Use an existing library and EAServer component project? in the wizard, and select your migrated library and component.

3. Migrating from PowerBuilder 10 or earlier

3.1 Toolbar changes in PowerBuilder 10.5

In the Menu painter, you can now add a toolbar to a standalone main window as well as to an MDI frame. PowerBuilder adjusts the size of the main window to accommodate the toolbar. If your application currently uses a visual user object as a toolbar in a main window, the adjustments that PowerBuilder makes might affect the display of your toolbar and conflict with adjustments that your scripts make to display microhelp.

You can replace your toolbar user object with a toolbar designed in the Menu painter or continue to use your existing toolbar. To ensure that your existing toolbar displays correctly, set the window?s ToolbarVisible property to false in a script or on the Toolbar page in the Properties view. To avoid conflicts, you should also move any microhelp position adjustment code into an event that runs after the Open event of the window.

3.2 Icon changes in PowerBuilder 10.5 (IM)

In PowerBuilder 10.5, many of the icons used in the PowerBuilder and InfoMaker user interfaces were changed. When you migrate an application to PowerBuilder 10.5, any stock icons used in the application are updated automatically. For users who prefer to use the existing icons, a zip file that contains 24 icon files and more than 500 bitmap files used in previous versions of the products is available on the CodeXchange Web site.

3.3 Migrating components to EAServer 6.0.1 or later

Intercomponent calls from a PowerBuilder component running in EAServer 6.0.1 require proxies for all called components. With earlier versions of EAServer, a PowerBuilder component is sometimes able to call another PowerBuilder component running in the same server without the use of a proxy, because the PowerBuilder VM creates a proxy for the component dynamically using method names that match the names of the component's methods.

In EAServer 6.0.1 and later, PowerBuilder components are wrapped as EJBs, providing an extra layer of security and preventing the PowerBuilder VM from generating a proxy with names that match the component's method names dynamically. Therefore, you must create a proxy object for all components you invoke with intercomponent calls. Without a proxy object, the TransactionServer object cannot obtain the correct method names of the component you are calling.

3.4 Creating an EJB client application for EAServer 6.x

Building EJB client applications for EJBs running in EAServer 6.x requires you to take some additional steps when you create the EJB client proxy and when you create the client.

To generate a proxy for an EJB deployed to EAServer 6.x:

   1. Copy the packagename directory from the %DJC_HOME%\deploy\ejbjars\ directory on the server to the client computer, where packagename is the package that contains the EJB you want to use.
   2. Add this directory to the Classpath on the Select EJB Component dialog box in the EJB Proxy Project painter.
   3. Generate the proxy.

To create an EJB client application for an EJB deployed to EAServer 6.x:

   1. Copy the eas-server-14.jar file (or eas-server-15.jar if you are using JDK 1.5.x) from the %DJC_HOME%\lib directory to the client computer and include its full path in the client?s classpath.
   2. Copy the stub files from %DJC_HOME%\genfiles\java\classes\ directory to the client computer and include this path in the client?s classpath.
   3. Copy the packagename directory from the %DJC_HOME%\deploy\ejbjars\ directory on the server to the client computer, where packagename is the package that contains the EJB you want to use and include this path in the client?s classpath.

If you copied these files and directories to a directory on the client called EAServer6, and you want to use an EJB in the datamapping package, the client classpath setting might look like this:

Classpath=D:\EAServer6\lib\eas-server-14.jar;D:\EAServer6\genfiles\java\classes;D:\EAServer6\deploy\ejbjars\datamapping

3.5 PowerBuilder system types as variable names in proxies

In PowerBuilder 10.5 and later versions, system types cannot be used as variable names in Web service proxies. If a PowerBuilder system type is used as a variable name, the Web Service Proxy wizard renames the variable by applying the prefix ws_. If you are migrating Web service applications from PowerBuilder 10.2 or earlier and regenerating the Web service proxies in PowerBuilder 10.5 or later, your code may need to be modified to reflect the change in variable names.

PowerBuilder system types include not only the objects and controls listed on the System tab page in the PowerBuilder Browser, but also the enumerated types listed on the Enumerated page in the Browser, such as band, button, encoding, location, and weekday. For example, if you build a Web service from a PowerBuilder custom class user object, and one of its functions has a string argument named location, in the proxy generated for that Web service, the argument is changed to string ws_location.

3.6 OLE DB performance with Microsoft SQL Server

In PowerBuilder 10.5.2 and later, when you use the OLE DB database interface with a Microsoft SQL Server database and retrieve data into a DataWindow or use an embedded SQL cursor in a SELECT statement, server-side cursors are used to support multiple command execution. If this has a negative impact on performance, try increasing the size of the Block database parameter to 500 or more, or adding the following line to the [Microsoft SQL Server] section in the PBODB initialization file to turn off server-side cursors:

Code: pb

ServerCursor = 'NO'

3.7 Change in behavior of OpenTab

A change was made in PowerBuilder 10.2.1 Build 9716, PowerBuilder 10.5.1 Build 6505, and PowerBuilder 11.0 Build 5021, to correct an anomalous behavior when the SelectedTab property was applied at runtime to a tab whose Visible property was set to false.

As a result of this change, there is a change in the behavior of the OpenTab and OpenTabWithParm functions. In previous releases, calling the OpenTab or OpenTabWithParm function to open a user object as a tab page displayed the tab page even if the user object?s Visible property was set to false. In current releases, the user object?s Visible property must be set to true for the tab page to display.

3.8 RichTextEdit control and RichText DataWindow changes (IM)

PowerBuilder 10.5 uses a new rich text editor to support the RichTextEdit control and the RichText DataWindow presentation style. The new editor brings a modern look and includes some new features, including the ability to name and use formatting styles. The new rich text editor supports a subset of the RTF specification version 1.6. Most of the properties and functions of rich text objects in previous versions of PowerBuilder continue to be supported by the new editor. When you import rich text objects from previous versions of PowerBuilder, any obsolete properties and functions are ignored.

There are some differences in behavior that may require you to make some changes in your applications. For example, when you migrate applications created in older versions of PowerBuilder, the InputFieldsVisible property in RichTextEdit controls and in RichText DataWindow objects is automatically set to ?false? in the migrated applications. You must set this property to ?true? to see data in the input fields. You must set this property and the InputFieldNamesVisible property to ?true? to see text labels for the input fields in a rich text control.

For more information about changes, see the section on Rich text enhancements in the New Features in PowerBuilder 10.5 guide on the Sybase Product Manuals Web site.

3.9 Some PSR files must be regenerated (IM)

PSR files created in builds of PowerBuilder 10.0 or 10.0.1 prior to EBF build 6044 cannot be opened in later builds of PowerBuilder or InfoMaker. You must regenerate the PSR file in a later build.

4. Migrating from PowerBuilder 9 or earlier

4.1 Unicode changes (IM)

PowerBuilder 10 is Unicode enabled. The source code in PowerBuilder 10 PBLs is encoded in UTF-16LE. UTF-16LE is a Unicode encoding scheme that serializes a UTF-16 code unit sequence as a byte sequence in little-endian format, in which multiple-byte numerical values are stored with the least significant byte first. PBLs developed in earlier versions of PowerBuilder contain source code in ANSI or DBCS format. When you migrate applications to PowerBuilder 10, each PBL is first migrated to the new version of PowerBuilder, as in previous releases. Then PowerBuilder converts the source code from ANSI or DBCS to Unicode, performs a full build, and saves the source code back to the same file.

As a result of this change, some new functions have been added and there are changes in the syntax of file-related functions and external function calls. For more information about these changes, see the Unicode support section in the New Features topic in online Help and the section on Unicode in Application Techniques.

4.2 Automatic changes made when you migrate

When you migrate an application from a previous release, the source code is converted to Unicode and the following changes to your source code are made automatically:

The clause ALIAS FOR functionname ;ansi is appended to external function declarations that return a string, char, or structure datatype or have a string, char, or structure value as an argument. This indicates that the arguments and/or return values should be treated as ANSI. If an ALIAS FOR clause is already present, only ;ansi is added. If ;ansi is not appended to the function name, strings are treated as Unicode.

The FromAnsi, FromUnicode, ToAnsi, and ToUnicode functions will be removed from a future version of PowerBuilder. The migration tool replaces them with the appropriate syntax of the Blob or String function.

No changes are made to the code if the PBL has already been migrated to PowerBuilder 10.

In a DBCS environment, you can check the "Automatically convert DBCS string manipulation functions" check box on the Migrate Application dialog box to modify your code to comply with changes required for Unicode support. Do not check this box in an SBCS environment. If you check this box, the W suffix is removed from PowerScript string-manipulation functions such as LenW and RightTrimW, and an A suffix is added to the following PowerScript functions: Fill , Left, Len, Mid, Pos, Replace, and Right. The changes to string-manipulation functions described in the documentation also apply to DataWindow expression functions. However, the migration process does not modify DataWindow expression functions automatically.

4.3 ImportFile size limit

PowerBuilder 10.0 and later versions are Unicode enabled. If your application uses the ImportFile method to import very large text files (approximately 839,000 lines) into a DataWindow or DataStore, ImportFile returns the error code -15. Larger text files could be imported in ANSI versions of PowerBuilder.

4.4 Migrating Web and JSP targets

Web targets that use PowerDynamo cannot be migrated directly to PowerBuilder 10 and must be rewritten using an alternative model such as JavaServer Pages or Active Server Pages. For information about converting PowerDynamo Web sites created using PowerBuilder to JSP, see the Technical Document Converting 4GL Web Pages from PowerDynamo to JSPs.

Web and JSP targets that use the Web DataWindow and were created in earlier versions of PowerBuilder must be modified to use the HTMLGenerator100 component. Most other Web and JSP targets can be opened and deployed in PowerBuilder 10 without modification. See Section 3.4, "JSP object model changes" for an exception. As a precaution, you should make backup copies of the target directories before making modifications.

4.5 JSP object model changes

Global control variables in the JSP object model have been changed to local variables to make JSP pages thread safe. If you want to refer to another control in a server-side event, you must qualify the name of the control with the string "psPage". For example, in previous releases, the following code in a button's ServerAction event sets the context of a single-line edit control:

Code: pb

sle_1.value = "abc";

In PowerBuilder 10 (and PowerBuilder 9 build 7151 and later), use the following statement instead:

Code: pb

psPage.sle_1.value = "abc";

4.6 DBCS text in object properties is not converted correctly (IM)

DBCS applications can be migrated successfully on operating systems with a DBCS-compatible locale. However, on an operating system with an English locale, DBCS characters display as garbage characters when the font property of an object is set to a font that does not support DBCS characters. To work around this issue, change the font to Tahoma after migration. [CR 355908]

4.7 XML string encoding

In PowerBuilder 10, the XML parser cannot parse a string that uses an eight-bit character code such as windows-1253. For example, a string with the following declaration cannot be parsed:

Code: pb

string ls_xml

ls_xml += '<?xml version="1.0" encoding="windows-1253"?>'

You must use a Unicode encoding value such as UTF16-LE.

4.8 Runtime errors in EAServer

In PowerBuilder 7, if a runtime exception was raised by a PowerBuilder component running in EAServer, the transaction was rolled back and the exception was thrown back to the client. In PowerBuilder 8, the behavior was changed so that the transaction was committed before the exception was thrown back. In PowerBuilder 10, PowerBuilder 9.0.2, and EBF releases of PowerBuilder 8 and PowerBuilder 9.0.1 dated February 27, 2004 or later, the default behavior has been reverted to the behavior in PowerBuilder 7 and the transaction is rolled back.

In PowerBuilder 10, PowerBuilder 9.0.2, PowerBuilder 9.0.1 EBF Build 7066 and later releases, and PowerBuilder 8.0.4, you can control this behavior using the PBRollbackOnRTError environment variable. When this environment variable is set to 'y', 'yes', or 'true', the transaction is rolled back before the exception is thrown back to the client. [CR 319543]

4.9 Using masks with "as is" characters

You can define a mask that contains "as is" characters that always appear in the control or column. For example, you might define a numeric mask such as Rs0000.00 to represent Indian rupees in a currency column. In PowerBuilder 9.0.1 or later, you cannot enter a plus or minus sign to represent positive or negative numbers in a mask that contains "as is" characters. In previous releases, you could enter a plus or minus sign, but the resulting behavior was inconsistent in DataWindow columns.

The preferred method of creating a currency edit mask is to use the predefined currency(7)] - International mask. You can change the number in parentheses, which is the number of characters in the mask including two decimal places. When you use this mask, PowerBuilder uses the currency symbol and format defined in the regional settings section of the Windows control panel. You can enter negative values in a column that uses a currency mask. [CR 309118]

4.10 Format of WMF files saved from DataWindows changed

In PowerBuilder 9.0, the format of WMF files created by saving a DataWindow object was changed to fix a crash issue. However, the fix removed the header information that allows the WMF file to be viewed in other applications. The format has been changed to restore the header information while preserving the fix. This change is in PowerBuilder 9.0 EBF builds 6096 and greater and in PowerBuilder 9.0.1, 9.0.2, and 10. [CR 292406]

4.11 MTS/COM+ components must be redeployed

Due to changes in the PowerBuilder VM in PowerBuilder 9.0.1, you must redeploy existing components to MTS or COM+ if you want to call them from PowerBuilder 9.0.1 and later clients. If you do not redeploy the components, calls to functions of the TransactionServer and ErrorLogging objects return incorrect values.

4.12 Change in Date function behavior

When you use the Date function with a string argument, PowerBuilder attempts to match the input string to a date format in the regional settings on the computer. In PowerBuilder 10 and later, if a complete match is not found, PowerBuilder attempts a partial match. For example, if you use Date('01-JAN-1900') and PowerBuilder finds the partial match (dd-MMM-yy), PowerBuilder parses the first two numbers of the year and gets 19. The 2-digit year is interpreted as a year between 1930 and 2029, and the date returned is 1/1/2019.

5 Migrating from PowerBuilder 8 or earlier

5.1 Changed format of PSR files (IM)

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.

5.2 Source code control changes

PowerBuilder 8 provided a direct connection to external SCC-compliant source control systems, and additional changes were made in PowerBuilder 9.0. Before migrating a source-controlled project from PowerBuilder 8 or earlier to PowerBuilder 9 or 10, read the chapter on using source control in the PowerBuilder User's Guide.

5.3 ScrollToRow behavior change

The ScrollToRow method triggers the RowFocusChanging and RowFocusChanged events. In PowerBuilder 7, both events occurred after focus changed to the new row. This behavior was changed in PowerBuilder 9 so that RowFocusChanging could be coded to cancel the scroll. However, this change caused both events to be triggered before focus changed to the new row. In PowerBuilder 9.0.1 Build 7136 and later, the RowFocusChanging event is triggered before the scroll occurs, and the RowFocusChanged event is triggered after the scroll occurs. [CR 345104]

5.4 Web ActiveX deployment requirements (IM)

Microsoft stopped shipping the Microsoft Java VM as of the Windows XP SP 1a release and the Windows 2000 SP 4 release, and the Microsoft Java VM is not supported in PowerBuilder 9 or later. If you use the DataWindow Web control for ActiveX and your Web page uses a JDBC connection, the Web ActiveX has additional deployment requirements:

    * The Sun JRE 1.2 or later must be installed on the client. Users can download the latest version of the JRE from the Sun Java Web site.
    * The path to the file jvm.dll (...\JRE\bin\client for JRE 1.4 or later and ...\JRE\bin\classic for JRE 1.2 or 1.3) must be added to each user's system PATH environment variable.
    * The following files must be in a directory in the client's system PATH environment variable: pbjvm90.dll, pbvm90.dll, and libjcc.dll for PowerBuilder 9, or pbjvmXXX.dll and pbshrXXX.dll for later versions.
    * The pbjdbc12XXX.jar file, which contains class files required by the Web ActiveX, must be deployed to the client. You can deploy the JAR file by referencing it in the CODEBASE attribute of the Object element in your Web page.
    * Java classes required by your database vendor's client layer must be available on the client. They can be added to a CAB file that is referenced in the CODEBASE attribute of the Object element in your Web page. For example, if you are using Sybase jConnect to connect to a database, the jconn2.jar file should be included in the CAB file. If the client layer is provided in a JAR file, it can be referenced directly in the CODEBASE attribute.

6 Migrating from PowerBuilder 7 or earlier

6.1 Adding targets to a workspace

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 10. For information about using workspaces and targets, see Chapter 1 in the User's Guide.

6.2 Distributed PowerBuilder is not supported

PowerBuilder 7 was the last version of PowerBuilder that incorporated distributed PowerBuilder functionality. Sybase recommended the use of EAServer in place of distributed PowerBuilder for distributed and Web applications in PowerBuilder 7 and later.

The Transport object and its associated properties and methods are obsolete in PowerBuilder 8 and later and were removed from PowerBuilder 9. 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 were removed from the New dialog box.

6.3 Reserved words

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.

6.4 SystemError event change

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.

6.5 IsValid function change

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.

6.6 Format for color options changed (IM)

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:

Code: 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:

Code: ini

ForeignKeyLineColor=16711680
IndexKeyLineColor=255
PrimaryKeyLineColor=32768

If you plan to use your PowerBuilder 7 PB.INI file, or the [Database] section from it, with PowerBuilder 8 or later, you should first delete all the color settings in the [Database] section. If you do not, the colors used might make tables unreadable in PowerBuilder 8 or later. You can reset custom colors in the Object Colors page of the Database Preferences dialog box in PowerBuilder 8 or later.

6.7 Web DataWindow migration issues

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 later releases 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.

6.8 DataWindow method return values for empty DataObject property

In PowerBuilder 8.0.2 and later, the value returned when there is no DataWindow object assigned to a DataWindow control or DataStore has been standardized for the methods listed in Table 1. Some of these return values are different from the values returned in PowerBuilder 7 and earlier releases. SetFilter is included in the table, but its return value was changed from 1 to -1 in PowerBuilder 8.0.4, not PowerBuilder 8.0.2.

Table 1: Return values when no DataWindow object is assigned




6.9 ScrollNextRow and ScrollPriorRow behavior change

In PowerBuilder 8 and later, the DataWindow methods ScrollNextRow and ScrollPriorRow trigger these events in the order shown:

    * RowFocusChanging
    * RowFocusChanged
    * ItemFocusChanged
    * ScrollVertical

In PowerBuilder 7 and earlier, the ScrollVertical event was triggered before the other events. You should no longer use these methods in the ScrollVertical event. Doing so causes the same series of events to be triggered repeatedly until the last or first row in the DataWindow is reached. [CR 323263]

6.10 Changed behavior of OpenSheet functions

In PowerBuilder 8 and later, the OpenSheet and OpenSheetWithParm functions might throw a runtime error on failure instead of returning -1. For example, this occurs when the optional windowtype argument is invalid. To ensure that this error is trapped, wrap the call in a try-catch statement in addition to checking the return value:

Code: pb

integer li_ret
try
li_ret = OpenSheet(w_child, "w_child_1", MDI_User, 2, Original!)
if li_ret <> 1 then MessageBox("OpenSheet failed", "Check arguments")
catch (RuntimeError rt)
MessageBox("OpenSheet failed", rt.GetMessage() )
// Handle error
end try

7 Migrating from PowerBuilder 6.5 or earlier

7.1 Nested reports in DataWindow objects renamed (IM)

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. Since names are assigned sequentially, 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 with a name already used for another DataWindow object, such as dw_2, could cause a GetChild/ShareData or 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 you migrate the DataWindow object, you can change the prefix back.

7.2 Icons for windows must be assigned

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!.

7.3 ListView and TreeView controls events changed

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.

7.3.1 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. In PowerBuilder 6 both pbm_rbuttonup and pbm_tvnrclicked fire.

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 causes it to become permanently selected. To duplicate this behavior in PowerBuilder 7 and later, place the line of code this.SelectItem(handle) in the RightClicked! event of the TreeView before triggering (or otherwise executing) code from the pbm_rbuttonup event.

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.

7.3.2 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 2 shows when events are fired in PowerBuilder 7 and later.

Table 2: Events fired in ListView



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:

Code: pb

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:

Code: pb

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

The pfc_u_lv and pfc_uv_lvs objects have been modified to use pbm_contextmenu instead of pbm_rbuttonup.