Use PowerBuilder System Functions Instead of External Functions
The internal workings of PowerBuilder system functions are optimized to suit .NET deployment and, hence, if your application uses external functions, try to replace them with equivalent PowerBuilder system functions.

For example, some applications use external DLL functions to get the current directory in its code whereas an equivalent PB system function GetCurrentDirectory() already exists. PowerBuilder .NET WebForm features use a virtual file system to emulate a file system on the server for each client, so in this scenario calling an external function to get the current directory will fail to work on a virtual file system. Replace the code with the PB system function GetCurrentDirectory().

Response Windows and Message Boxes
Response windows and message boxes are supported in the .NET WebForm implementation of PowerBuilder. But they consume more server-side resources than other window types and can lead to poor performance. Use response windows and message boxes when absolutely necessary in the application. Hiding a response window in a .NET WebForm application may not work as expected, so always close the response window when its use is finished.

You can rework your application to minimize the use of response windows by implementing the same logic with other window types. Similarly if the message boxes are used to convey a message to the user, you use the static text display in the window rather than the message boxes.

Yield () PowerScript Function
Yield () PowerScript function is supported in the .NET WebForm application, but similar to response windows, Yield () function also consumes lots of server-side resources and generates frequent post backs with the server.

Normally, the Yield statement makes the performance of a PowerBuilder native (Win32) application twice as slow and the .NET WebForm application 10 times slower.

For example, the Figure 3 and Figure 4 dictate the time taken to retrieve a DataWindow without and with a Yield () function, respectively, in a .NET WebForm application.

The pieces of code in the DataWindow events are:

//Instance variable
long il_cpu_starttime
long il_cpu_endtime

RetrieveStart event of dw_1

st_1.Text = "Retrieving ... please wait"
il_cpu_starttime = CPU()

RetrieveRow event of dw_1

if cbx_yield.Checked then

if mod(row,20) = 0 then
yield()  //invoke yield() once in every 20 rows
end if

end if

RetrieveEnd event of dw_1

il_cpu_endtime = CPU()
long ll_retrieve_time
ll_retrieve_time = il_cpu_endtime - il_cpu_starttime
St_1.text = " Retrieve Finished. Time taken to retrieve: "+string(ll_retrieve_time)+" milliseconds"

Timer Event and Timer PowerScript Function
Timer event and Timer () function is also supported in the PowerBuilder .NET WebForm application, but they generate postbacks periodically based on the interval set in the Timer () function. If your application is an interactive data entry application, then using the Timer event will cause an interruption due to periodic postbacks and can never complete the data entry.

It is advisable not to use the Timer event and Timer () function if the application depends on data entry.

JavaScript Keywords in the DataWindow Object
Using JavaScript keywords as DataWindow column names causes a runtime error in a .NET WebForm application. You must rename these columns before deploying the DataWindow objects to the Web. For a complete list of JavaScript keywords, refer to Sun Microsystems' Web site.

You can download and run the "JavaScript Keyword Search Tool" created by Bruce Armstrong from the PowerBuilder CodeExchange Web site, which can check and report JavaScript keywords used in your DataWindow.

Buttons in DataWindow Objects Must Be Named
In older versions of PowerBuilder, you can include button controls with empty names in DataWindow objects. In a .NET WebForm application, it can cause a runtime error if you don't assign proper names to all button controls inside DataWindow objects.

Things to Check for If the DataWindow Generates Too Many Postbacks
In a .NET Web Form application, if a DataWindow frequently refreshes even for simple actions, check whether the following events contain any PowerScript code:

• Clicked
• RowFocusChanging
• RowFocusChanged
• ItemFocusChanged
• ItemChanged

The scripts in these events contribute to frequent postbacks to the server. Try replacing the functionality of the events with alternative approaches. One recommendation is:

• RowFocusChanging: Use a row-level DataWindow button and copy the script in the RowFocusChanging to a ButtonClicking event of the button.
• RowFocusChanged: Use a row-level DataWindow button and copy the script to a ButtonClicked event.
• ItemFocusChanged: Avoid it entirely. If possible, use a DataWindow button to code the event.
• ItemChanged: Use an alternative window control such as CommandButton and put the functionality in the window CommandButton clicked event.

Global Configuration Properties (web.config)
The global configuration properties of a .NET WebForm application can be set in the .NET WebForm project painter in the PowerBuilder IDE (see Figure 5). These global properties are written to an XML-based web.config file generated in the Web application folder in IIS. The properties set there will enhance application presentation and improve application performance. The properties can also be modified by directly opening the web.config file in a text editor (WordPad) from the Web application folder after the application is deployed from the PowerBuilder IDE.

The following properties can be modified in the global configuration properties of a .NET WebForm application to enhance presentation and boost application performance.

PBDataWindowEnableDDDW
Setting this property to "true" renders the DDDW as a true multi-column DDDW in a .NET WebForm application similar to a client/server application (see Figure 6). This not only enhances the presentation, but also boosts the performance because the default DDDW rendering in .NET WebForm is by the HTML select tag. The default HTML select tag with the same set of data repeats for each row of the DataWindow; if there is more than one DDDW in a DataWindow, it further increases the results of the HTML code.

PBDataWindowScriptCallbackDDDW
Setting this property to "true" together with "PBDataWindowEnableDDDW" further improves the performance of the application, because DDDW are loaded only on demand. The DDDW is not sent to the browser until the DDDW column is clicked. When the DDDW column is clicked, using an ASP.NET script callback technique, the DDDW is generated and sent to the browser.

PBDataWindowRowsPerPage
The value set for the property limits the number of rows per page that a DataWindow control can display. The PBDataWindowRowsPerPage property helps to reduce the size of the HTML response and so improves the performance of the application. It also enables the DataWindow Pagination, which can be customized using DataWindow page navigation properties.

PBCacheAndSharedDWs
This property allows sharing data from the read-only DataWindow across different sessions, thereby avoiding duplicate retrieval of the same DataWindow by multiple sessions. The data in the primary, filter, and delete buffers will be shared. The name of the DataWindow objects that will share data has to be specified in a comma-separated format to PBCacheAndSharedDWs property. However, the following restrictions apply when sharing a read-only DataWindow:

• Only a single invocation of Retrieve() is allowed.
• The DataWindow should not have retrieval arguments.
• No filtering or sorting, insertion or deletion is allowed.
• No modification of data is allowed.
• No ShareData or ShareDataOff method is called in the code on this DataWindow.
• No Update () is called.
• PBCacheAndSharedDDDWs

Similar to sharing a read-only DataWindow, the DDDWs can be shared across multiple sessions. The name of the DDDWs that will share data has to be specified in a common-separated format for this property. All the restrictions listed above for sharing a DataWindow apply to DDDWs too.

Conclusion
I conclude this article with the wish that you can now successfully refactor and deploy your PowerBuilder application as a .NET WebForm application and find it interesting when it runs on an IE browser. Good luck!

Further Reading
You can refer to the Sybase website to read more about the latest PowerBuilder releases and features and other details.