Design-level considerations

Although stricter compiler enforcement for the .NET environment can catch coding errors typically tolerated by the PowerScript compiler, the .NET environment might also require changes in application design that are not necessarily caught by the compiler.

Use PowerBuilder system functions

For a PowerBuilder .NET Web Forms application, use PowerBuilder system functions instead of external functions whenever possible. Some system functions, such as the functions for file operations, are implemented differently for Windows Forms and Web Forms. If you always use PowerBuilder system functions, you do not need to worry about these differences.

Use GetCurrentDirectory Some applications use external DLL functions to get the current directory. For PowerBuilder Web Forms applications, you must use the GetCurrentDirectory standard system function instead.

PowerBuilder Web Forms use a virtual file system to emulate a file system on the server for each client. The virtual file system is actually a folder on the server computer to which the ASPNET user (IIS 5), the IIS_WPG user group (IIS 6), or the IIS_USRS user group (IIS 7) has write permission. Calling an external function to get the current directory from the virtual file system fails.

Use regional formats based on client or server settings

The PBCultureSource global property determines whether a .NET Web Forms application uses client or server regional settings. Client regional settings are specified by the first language listed in the Language Preference dialog box of the Internet Explorer browser. However, If you set PBCultureSource to “client” and no language is listed in the Language Preference dialog box, server-side regional settings are used instead.

Server regional settings are those set for the ASP.NET user or user group on the server machine. You can use the IIS Manager to change the default regional settings in the Globalization section of the Web.config files for your Web Forms applications, or you can modify the Web.config files manually after you deploy your applications.

The regional settings specify formats for the following items:

The regional settings apply to DataWindow columns of relevant datatypes and to the following PowerScript controls and functions:

The regional settings selection can also apply to objects you include in .NET conditional compilation blocks. It does not apply to button labels in message boxes or other system dialog boxes.

You can set the PBCultureSource global property on the Configurations tab in the Web Forms Project painter before you deploy a project. By default, applications use the regional settings specified by the Web Forms server.

Work around unsupported features

Avoid using Handle Some applications call the Handle function to get the window handle of a control and pass it to an external function. This does not work in a Web Forms application.

Restrict impact of unsupported events Since unsupported events are never triggered, do not allow the logic in unsupported events to affect the logic flow of other events or functions. For example, if the code in an unsupported event changes the value of an instance variable, it can affect the logic flow in a supported event that uses that variable. Remove this type of coding from unsupported events.

Avoid name conflicts PowerBuilder allows two objects to have the same name if they are of different types. For example, you can use the name s_address to define a structure and a static text control or a nonvisual object in the same PowerBuilder application. The .NET environment does not allow two classes to have the same name. To enable your application to compile in .NET, you must not give the same name to multiple objects, even if they are of different types.

Using structures in inherited objects Using local structures in inherited objects can prevent deployment of a .NET project. To deploy the project, replace all local structures defined in inherited objects with global structures.

AcceptText is redundant In the Web Forms deployment version of the DataWindow, explicit invocations of AcceptText are redundant but harmless. Any loss of focus of a DataWindow implicitly invokes AcceptText.

Avoid hindrances to application performance

Some functions and features that are fully supported can hinder application performance. Use these functions and features sparingly and avoid them where possible.

Response windows and message boxes Although response windows and message boxes are supported in Web Forms, use them only when absolutely necessary. Response windows and message boxes require more server-side resources than other kinds of windows.

Hiding a response window in a Web Forms application does not work properly and can cause the application to fail. Instead of hiding a response window, always close it when the user has finished with it.

Yield Although the Yield function works in a Web Forms application, avoid it whenever possible, because it requires additional server-side resources.

Timers Timers are supported in Web Forms applications, but they periodically generate postbacks and can impede data entry. Use them sparingly and avoid including them on forms that require data entry. When you use them, delay the postbacks by appropriate scripting of client-side events.

PFC The DataWindow service in PFC handles many DataWindow events. Each event causes a postback for each mouse-click, which adversely affects application performance. Delay postbacks by scripting client-side events or cache DataWindow data in the client browser by setting the paging method property for the DataWindow object to XMLClient!.